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I.  INTRODUCTION 


A.  BACKGROUND 

Technology  and  competition  have  significantly  changed  knowledge 
management. 

We  are  living  in  a  world  of  rapid  change  driven  by  globalization,  the 
knowledge-based  economy  coupled  by  ever-fast  development  of 
information,  communication  and  technology.  This  change, 
however,  not  only  poses  some  challenges,  but  also  offers 
opportunities  for  both  private  and  public  sectors  alike.  (Cong  & 
Pandya,  2003) 

The  opportunities  provided  by  formalized  knowledge  management  are  intended 
to  improve  handling  and  communication  of  technical  information  in  the  Platform 
and  Payload  Integration  Department  at  Naval  Undersea  Warfare  Center  Division 
Newport. 

Knowledge  management  has  many  definitions  and  means  many  things  to 
different  people.  The  Department  of  the  Navy  Chief  Information  Officer  defines 
knowledge  management  (KM)  as  the  integration  of  people  and  processes, 
enabled  by  technology,  to  facilitate  the  exchange  of  operationally  relevant 
information  and  expertise  to  increase  organizational  performance  (Wennergren, 
2005).  Love,  Irani,  and  Fong  (2004)  define  KM  as  “sharing  and  leveraging 
knowledge  within  an  organization  and  outwards  toward  customers  and 
stakeholders.”  There  are  multiple  definitions  of  KM  but  each  has  a  similar  theme, 
which  is  sharing  and  leveraging  knowledge  to  increase  understanding.  This  is 
where  knowledge  management  can  help  to  improve  the  Platform  and  Payload 
Integration  Department. 

The  Naval  Undersea  Warfare  Center  (NUWC)  Division  Newport  is  a  Naval 

Sea  Systems  Command  field  activity.  NUWC  Division  Newport  employs  2544 

individuals.  Seventy-five  percent  of  the  workforce  is  made  up  of  scientists  and 

engineers,  and  the  remaining  25%  is  support  personnel.  Over  45%  of  the 

scientists  and  engineers  have  advanced  degrees  (Lefebvre,  2008).  NUWC 
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performs  research,  development,  test  and  evaluation,  engineering,  analysis  and 
assessment,  and  Fleet  support  to  the  United  States  and  foreign  navies  (Lefebvre, 
2008).  Its  primary  customer  is  the  U.S.  Navy  and  is  involved  in  foreign  military 
sales.  NUWC  has  eight  technical  departments,  which  are  involved  in  support, 
development,  or  analysis  of  the  systems  and  programs  shown  in  Figure  1,  Figure 
2,  and  Figure  3.  The  systems  include  submarines,  surface  ships,  weapons,  and 
unmanned  vehicles.  NUWC  is  a  Navy  Working  Capital  Fund,  which  means  it 
operates  similarly  to  a  privately  owned  business.  It  is  like  a  business  because  it 
is  accountable  for  efficient  delivery  of  products  and  services,  in  exchange  for 
funding  it  recieves  from  sponsoring  commands  (Lefebvre,  2008).  It  differs  from 
private  business  because  it  acts  like  a  nonprofit  organization  that  does  not 
compete  with  private  industry. 
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Figure  1 .  Submarine  systems  under  NUWC  responsibility. 


This  figure  shows  all  of  the  systems  that  NUWC  is  responsible  for.  The  launchers  division 
works  on  launchers  which  include  the  torpedo  system,  unmanned  undersea  vehicles,  and 
countermeasures.  From  (Lefebvre,  2008). 
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Figure  2.  Surface  ship  systems  under  NUWC  responsibility. 

This  figure  shows  the  areas  that  NUWC  is  involved  in  on  surface  ships.  The  launchers 
division  works  on  countermeasures  and  torpedo  tubes.  From  (Lefebvre,  2008). 
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Figure  3.  Future  NUWC  projects  under  development. 


This  figure  shows  the  development  projects  that  NUWC  is  working  on.  The  launchers 
division  works  on  advanced  payloads,  and  Unmanned  Vehicles.  From  (Lefebvre,  2008). 
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The  Platform  and  Payload  Integration  Department  is  one  of  the  eight 
technical  departments  at  NUWC.  The  Platform  and  Payload  Integration 
department  has  240  employees  that  perform  research,  development,  test  and 
evaluation,  engineering,  analysis,  and  Fleet  support  to  the  United  States  and 
foreign  navies  (Lefebvre,  2008).  Its  primary  role  is  to  develop  and  support 
submarine  launcher  systems  and  integrate  payloads  into  submarine  launcher 
systems.  The  integration  role  includes  insertion  of  new  payloads,  weapons  and 
vehicles  into  submarines  and  surface  ships.  The  payloads,  weapons,  and 
vehicles  include  unmanned  vehicles,  countermeasures,  torpedoes,  and  tactical 
missiles.  The  department  consists  of  two  divisions,  which  are  the  Missiles 
Division  and  the  Launchers  Division. 

If  implemented  correctly,  improved  KM  can  provide  improved 
organizational  performance  through  the  integration  of  people,  processes,  and 
technology.  It  could  provide  the  opportunity  to  improve  the  design  of  future 
systems,  improve  current  systems,  and  reduce  maintenance  turnaround  times  of 
Fleet  systems.  Implementation  of  KM  has  the  potential  to  improve  the 
organizational  performance  of  the  Launchers  Division. 

B.  PURPOSE 

The  purpose  of  this  thesis  is  to  conduct  research  and  provide 
recommendations  for  improved  knowledge  management  within  the  Launchers 
Division  of  the  Payload  and  Platform  Integration  Department  at  the  Naval 
Undersea  Warfare  Center.  It  not  only  will  support  internal  needs  for  the  conduct 
of  everyday  tasking,  but  will  also  meet  external  needs  for  long-term  initiatives. 

There  are  many  Department  of  the  Navy  challenges  that  the  Platform  and 
Payload  Integration  Department  is  undertaking.  These  challenges  support  the 
future  of  undersea  warfare  and  the  United  States  Navy.  One  of  the  more 
important  priorities  of  the  Navy  is  reduction  of  total  ownership  costs,  which  “will 
be  key  components  of  all  programmatic  discussions  and  decisions”  (Roughhead, 
2009).  The  purpose  of  the  reduction  of  total  ownership  cost  initiative  is  to  reduce 
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the  life-cycle  costs  of  Navy  Ships  as  a  response  to  shrinking  budgets.  Another 
initiative  is  support  of  the  “the  Ohio  Class  replacement  which  will  replace  the 
Ohio  Class  Ballistic  Missile  Submarines”  (Government  Accountability  Office, 
2010).  The  Ohio  Class  replacement  program  is  scheduled  to  “enter  the 
technology  development  phase  in  the  third  quarter  of  2010”  (Government 
Accountability  Office,  2010).  The  Launchers  Division  provides  technical 
expertise,  which  includes  systems  knowledge,  to  support  each  of  the  challenges. 

There  are  also  many  submarine  community  needs  that  can  be  addressed 
by  a  KM  system.  Recent  meetings  with  the  submarine  community  have  revealed 
that  “there  does  not  appear  to  be  any  method  to  capture  and  implement  lessons 
learned”  and  there  is  “lack  of  money  for  basic  needs  or  requirements”  (Ybarrondo, 
2010).  The  Fleet  also  has  “requested  explanations  to  better  understand  the 
engineering  standpoint”  (Ybarrondo,  2010)  in  cases  where  the  technical  direction 
does  not  make  sense  to  the  end  user.  There  are  other  instances  of  the  Fleet 
needing  increased  understanding  of  technical  decisions  and  products,  and 
elimination  of  redundant  problems.  Improved  system  knowledge  and 
communication  of  technical  status  of  systems  between  the  Fleet  and  Naval  Sea 
Systems  Command  (NAVSEA)  is  needed. 

In  order  to  meet  these  challenges  and  needs,  the  Launchers  Division  must 
create,  communicate  and  retain  launcher  system  knowledge.  The  knowledge 
includes  documentation  of  design  decisions  and  operational  support  for  existing 
submarines.  Launcher  system  knowledge  in  the  Launchers  Division  is 
dependent  on  personal  experience  and  individual  filing  systems.  No  central 
repository  exists,  resulting  in  losses  of  relevant  system  data.  An  improved  KM 
system  is  needed  to  capture  system  knowledge  from  all  engineering  activities, 
ranging  from  research  and  development  to  operational  support.  An  improved  KM 
system  may  enhance  the  Launchers  Division’s  ability  to  provide  the  data  to 
reduce  the  number  of  life-cycle  problems. 
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C.  BENEFITS  OF  STUDY 

This  study  directly  benefits  the  Payload  and  Platform  Integration 
Department  and  the  Navy  by  potentially  reducing  costs  and  the 
misunderstanding  of  technical  status  between  organizations.  Cost  reduction  can 
be  achieved  by  elimination  of  lost  technical  knowledge  and  improved  system 
maintenance.  Technical  knowledge  is  difficult  and  costly  to  recreate.  The 
architecture  description  could  also  serve  as  a  model  for  other  program  offices, 
Navy  laboratories,  DoD  organizations,  and  in-service  engineering  agents  that  are 
involved  in  development,  construction,  and  repair  of  Naval  Vessels. 

The  direct  benefit  of  this  thesis  to  the  Platform  and  Payload  Integration 
Department  and  the  Navy  is  due  to  the  potential  of  the  KM  system  to  generate 
significant  cost  savings  through  the  reduction  of  redundant  efforts.  Cost  savings 
from  the  reduction  of  redundant  efforts  will  allow  allocated  funding  to  be  used  on 
other  problems.  Resolution  of  additional  issues  allows  more  efficient  use  of  Navy 
resources.  The  additional  resources  could  be  used  to  improve  launcher  system 
performance. 

The  KM  system  could  also  provide  lessons  learned  from  similar  systems. 
Use  of  lessons  learned  has  the  potential  to  avoid  system  design  problems  and 
improve  launcher  system  personnel  performance.  Reduction  of  system  design 
problems  could  reduce  the  overall  cost  through  elimination  of  rework,  reduction 
of  maintenance  and  system  operation  issues  of  future  platform  and  payload 
development.  Improved  performance  of  launcher  division  personnel  will  have 
direct  effects  on  the  life-cycle  costs  of  launcher  systems.  This  could  have  direct 
benefit  to  future  Virginia  Class  platforms  and  the  Ohio  Class  Replacement 
Program.  It  also  could  serve  as  a  model  for  development  and  implementation  of 
other  Navy  KM  systems. 
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D.  RESEARCH  QUESTIONS 

This  thesis  answers  the  following  questions: 

•  What  is  an  improved  way  to  manage  technical  data  ranging  from 
design  to  operational  support  for  the  Launchers  Division  at  NUWC? 

•  What  is  the  best  high-level  architecture  description  for  the  technical 
KM  system? 

E.  SCOPE  AND  METHODOLOGY 

This  section  describes  the  scope  and  methodology  for  this  thesis.  The 
scope  defines  the  narrowly  focused  areas  researched  and  the  problem  space 
explored.  The  methodology  includes  conduct  of  research. 

1.  Scope 

The  scope  of  this  project  is  limited  to  the  Payload  and  Platform  Integration 
Department  Launchers  Division  technical  knowledge  management.  The  intent  is 
to  create  an  open  architecture  description  that  meets  the  Launcher  Division 
needs.  The  systems  architecture  description  is  subject  to  all  of  the  DoD  security 
requirements,  primarily  the  OPNAV  5000  series  but  will  not  provide  a  method  for 
implementation  of  these  guidelines.  The  architecture  description  supplements 
existing  systems  from  higher  tier  organizations  but  does  not  replace  them.  The 
architecture  description  reflects  the  constraint  that  the  initial  solution  on  which  it 
is  based  will  be  implemented  in  the  next  three  years.  The  development  of  a 
systems  architecture  keeps  cost  in  mind  but  does  not  provide  a  cost  analysis. 

2.  Methodology 

A  tailored  systems  engineering  process  is  applied  to  resolve  the  problems 
associated  with  KM  in  the  Platform  and  Payload  Integration  Department.  The 
high-level  process  is  shown  in  Figure  4.  This  process  generated  requirements 
that  results  in  a  recommended  system  architecture  description  that  makes  use  of 
KM  best  practices. 
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Figure  4.  Process  layout 

This  figure  shows  the  three  step  systems  engineering  process  layout.  The  steps 
correspond  to  each  of  the  chapters. 

The  Figure  4  process  has  three  distinct  sections:  problem  definition, 
requirements  development,  and  architecture  development.  The  problem 
definition  process  identifies  the  problem,  performs  a  detailed  situational  analysis, 
and  performs  a  review  of  KM  best  practices.  This  process  yielded  the  top-level 
requirements  and  selection  of  stakeholders,  which  are  used  in  the  requirements 
development  process.  The  requirements  development  process  consisted  of  a 
functional  analysis,  requirements  generation,  and  requirements  analysis.  The 
requirements  development  process  outputs  are  derived  requirements,  and  a 
functional  hierarchy,  which  are  used  in  the  architecture  development  process. 
The  architecture  development  process  consisted  of  concept  generation,  concept 
evaluation,  and  recommended  architecture.  The  output  of  this  process  is  an 
architecture  description.  The  feedback  loop  in  each  of  the  sections  is  included, 
because  the  problem  is  constantly  refined  and  bounded  as  the  solution  is 
developed.  Each  section  corresponds  to  a  chapter  in  this  thesis. 

The  process  was  created  to  provide  the  framework  for  creation  of  a  KM 
architecture.  The  process  is  based  on  implementation  of  a  successful  system. 
Chan  (2002)  concluded  that  success  depends  on  understanding  strategic 
business  needs,  employee  buy  in,  and  a  system  tailored  to  user’s  needs. 

The  system  for  the  Launchers  Division  was  created  for  meeting  the 
stakeholders’  needs  as  identified  in  the  surveys  and  observations.  The  best 
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system  is  the  one  that  meets  or  exceeds  all  of  the  top-level  requirements  and  is 
better  than  the  other  concepts.  This  thesis  answers  the  best  way  to  implement  a 
technical  KM  system  for  the  Launchers  Division  by  providing  an  architecture 
description  based  on  the  Figure  4  systems  engineering  process. 

The  Figure  4  processes  were  selected  to  answer  each  of  the  thesis 
questions.  The  problem  definition  process  provides  the  criteria  for  answering  the 
thesis  questions.  The  process  takes  inputs  from  the  stakeholders  and  combines 
them  with  KM  best  practices.  This  combination  provides  the  criteria  for  creation 
of  the  best  architecture  description.  The  requirements  and  architecture 
development  are  structured  processes  to  translate  the  criteria  generated  into  the 
architecture  description.  The  architecture  meeting  the  top-level  requirements 
makes  the  system  the  best  architecture  description  when  compared  to  the  other 
concepts. 

F.  CHAPTER  SUMMARY 

The  first  chapter  introduces  the  KM  problem,  the  benefits  of  the  study, 
research  questions,  and  scope  and  methodology.  It  provides  an  overview  of  the 
Launchers  Division  at  NUWC  and  KM.  The  problem  is  a  need  to  improve  the 
documentation  and  communication  of  information  within  NAVSEA  and  to  the 
Fleet.  An  enhanced  KM  system  could  improve  the  Launchers  Division  support  of 
the  Fleet  and  development  of  new  technologies.  The  following  chapters  use 
systems  engineering  to  develop  an  architecture  description. 
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II.  PROBLEM  DEFINITION 


A.  INTRODUCTION 

Problem  definition  is  the  most  important  step  in  systems  engineering.  The 
success  or  failure  of  a  project  depends  on  it.  The  problem  definition  process 
used  in  this  thesis  has  four  phases  shown  in  Figure  5.  The  phases  include 
stakeholder  identification  and  need,  situational  assessment,  KM  best  practices 
review,  and  synthesis  of  results.  The  feedback  loops  in  Figure  5  are  important 
because  each  of  the  phases  used  the  information  to  build  on  one  another.  This 
chapter  generates  top-level  requirements  that  are  utilized  in  the  requirements 
development  process. 


Feedback 


Figure  5.  Problem  Definition  Process 

The  problem  definition  process  combines  stakeholder  need  identification  with  a 
situational  assessment  and  best  practices  review. 

The  development  of  Figure  5  resulted  from  reviews  of  Buede  (2009), 
Blanchard  and  Fabrycky  (2006),  Sage  and  Armstrong  (2000),  and  Langford 
(2009).  The  stakeholder  identification  and  need  phase  identifies  stakeholders 

internal  and  external  to  Launchers  Division,  finds  their  needs,  and  bounds  the 
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problem.  The  stakeholders  and  their  needs  are  the  outputs.  The  situational 
assesment  evaluates  the  past,  present,  and  future  state  of  the  Launchers 
Division  KM  to  further  refine  the  needs  of  the  stakeholders.  The  output  of  the 
situational  assessment  is  refined  stakeholder  needs,  which  results  from  better 
understanding  of  the  stakholders  and  their  environment.  The  KM  best  practices 
review  conducts  a  literature  review  that  provides  insight  into  the  knowledge 
management  cycle  and  other  successful  systems.  Its  outputs  are  an 
understanding  of  the  KM  cycle  and  key  elements  of  a  KM  system.  The  synthesis 
of  results  phase  takes  the  inputs  from  the  other  three  phases  creating  the  top- 
level  requirements,  system  boundaries,  and  defined  stakeholders. 

The  feedback  loop  in  Figure  5  is  included  due  to  the  necessity  to 
constantly  refine  the  top-level  requirements  throughout  the  SE  process.  When  a 
problem  is  encountered  with  the  requirements,  it  can  have  an  effect  on  the  higher 
level  and  lower  level  requirements.  Problems  encountered  include  changing 
requirements,  funding,  conflicting  requirements,  and  roadblocks  that  cannot  be 
overcome. 

There  are  differences  between  internal  stakeholders  within  the  Launchers 
Division  and  external  stakeholders  outside  of  the  Launchers  Division.  Internal  to 
the  Launchers  Division  means  the  NUWC  employees  who  work  for  the  division 
and  those  who  have  access  to  its  information  systems.  These  include 
government  and  contractor  personnel.  External  stakeholders  are  the  customers, 
such  as  NAVSEA  headquarters,  contractors,  and  the  Fleet  that  do  not  have 
access  to  all  of  the  division’s  information  systems.  Access  to  information  differs 
between  the  internal  and  external  stakeholders. 

B.  STAKEHOLDER  IDENTIFICATION  AND  NEED 

Stakeholder  identification  and  need  is  an  important  part  of  the  SE  process. 
Without  stakeholders  needs  there  is  no  problem.  The  inputs  into  this  section 
were  generated  from  observation  and  the  surveys  described  in  Appendix  A.  The 
outputs  of  this  section  are  stakeholder  identification  and  their  needs. 
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Identification  of  stakeholders  is  a  major  part  of  the  problem  definition 
process.  Stakeholder  identification  is  intended  to  find  all  of  the  personnel  who 
are  going  to  be  involved  with  development,  fielding  and  disposal  of  the  intended 
architecture  description.  Feedback  from  the  other  phases  in  the  problem 
definition  process  resulted  in  the  selected  stakeholders.  The  stakeholders 
include  Launchers  Division  management,  Launchers  Division  engineers,  selected 
customers,  and  contractors.  The  selected  customers  include  Naval  Sea  Systems 
Command  program  offices  and  technical  warrant  holders,  and  submarine  Fleet 
representatives. 

Once  the  stakeholders  were  identified,  their  needs  were  analyzed.  The 
stakeholder  needs  were  generated  from  surveys,  and  the  situational  assessment. 
Not  all  of  the  stakeholders  were  surveyed.  Only  the  selected  stakeholders  who 
responded  to  the  request  for  conduct  of  the  survey  participated.  Twelve  people 
responded  to  the  survey.  Results  and  additional  information  on  the  survey  are 
presented  in  Appendix  A.  Note  that  there  are  solution  neutral  and  solution 
specific  needs  in  Appendix  A.  The  primary  needs  identified  are  a  system  to  store 
and  retrieve  data,  and  improvement  of  communication  between  the  stakeholders. 
The  system  should  be  easy  to  use,  and  provide  means  of  archiving  design 
decisions  and  system  history. 

The  following  are  primary  results  of  the  survey.  The  ranking  of  the 
stakeholder  needs  are  based  on  the  frequency  of  each  response. 

1.  Provide  a  searchable  database  that  stores  division  technical 
documentation. 

2.  Provide  a  usable  system. 

3.  Facilitate  communication  of  technical  knowledge  within  and  outside 
of  the  Launchers  Division. 

4.  Provide  backup  of  data.  This  system  should  be  redundant. 

5.  The  data  generated  by  the  system  shall  last  at  least  30  years. 
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The  results  reported  above  eliminate  solution-specific  requirements.  These 
include  use  of  Google™  desktop,  Microsoft  Access®,  and  Wikipedia®.  The 
survey  results  show  varying  levels  of  understanding  and  experience  throughout 
the  organization. 

The  stakeholder  identification  and  need  process  also  identify  system 
boundaries.  One  of  the  more  important  ones  is  the  system  is  limited  to  the 
Launchers  Division  product  line.  This  thesis  will  not  address  transfer  of 
unclassified  documentation  from  a  higher  classification  system.  Transfer  of 
information  from  one  system  to  another  is  very  hard  to  complete  and  outside  of 
the  scope  of  thesis. 

C.  SITUATIONAL  ASSESSMENT 

The  situational  assessment  further  defines  and  evaluates  the  initial 
problem  identified.  It  accomplishes  this  by  assessing  how  the  KM  system 
operated  in  the  past,  how  it  operates  in  the  present,  and  the  possible  future  state 
of  the  Launchers  Division  projects.  The  situational  assessment  methodology  is 
based  on  Sage  and  Armstrong  (2000)  and  Maier  and  Rechtin  (2000).  The  data 
for  the  situational  assessment  is  generated  from  research  on  and  observation  of 
the  available  systems  and  stakeholders  in  action. 

1.  Past 

The  description  and  results  of  internal  and  external  evaluations  of  the  past 
state  of  the  Launchers  Division  KM  are  described  in  this  section.  The  internal 
KM  evaluation  focuses  on  the  processes  and  technology  in  place  in  the 
Launchers  Division.  The  external  evaluations  consists  of  the  Missiles  division 
and  other  departments  within  NUWC.  The  inputs  are  the  problem,  observations, 
and  surveys.  The  output  is  insight  into  how  NUWC  division  Newport  KM  was 
conducted  in  the  past. 

The  internal  evaluation  consists  of  the  Launchers  Division  KM  processes 
and  technologies  that  are  used.  This  evaluation  was  accomplished  through 
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survey  responses  and  observation  of  the  current  system.  The  survey  reveals 
that  the  Launchers  Division  KM  processes  rely  on  system  experts  to  retain 
documentation  and  unwritten  system  knowledge.  This  process  is  highly 
dependent  on  the  diligence  and  the  willingness  of  the  individual  to  share, 
document,  and  archive  information.  Paper  and  microfiche  files  are  used  to  store 
technical  data.  If  the  system  expert  left  the  department  for  retirement  or  a  new 
position,  knowledge  transfer  is  dependent  on  that  individual  sharing  both  written 
and  unwritten  information  with  new  employees. 

The  Missiles  Division  KM  system  was  purchased  by  NAVAIR  from  Boeing 
in  the  early  1990s.  It  was  created  to  provide  a  system  to  support  life-cycle 
planning  and  history  of  the  Tomahawk  Missile  program.  It  is  called  the 
Tomahawk  Information  System.  It  provides  many  functions  including 
configuration  and  financial  management,  a  data  repository,  in-service  problem 
reporting,  and  design  information.  Tomahawk  Information  System  (TOMIS)  is 
available  to  relevant  stakeholders  using  a  secure  Web  site.  The  stakeholders 
include  the  Fleet,  program  office,  and  contractors  (Sujecki,  2010). 

Other  departments  at  NUWC  have  other  systems  that  are  used  for 
Knowledge  Management.  One  of  the  systems,  Advanced  Interactive 
Management  Technology  Center  (AIMTC),  is  used  for  submarine  combat 
systems  and  has  existed  since  the  1990s.  Since  2001,  AIMTC  has  provided 
real-time  chat  with  deployed  platforms,  which  was  considered  by  the  Fleet  to 
provide  outstanding  support  for  the  submarine  fire  control  systems  (Iriye,  2004). 
AIMTC  also  has  a  data  retention  capability  that  allows  maximization  of  data 
collection  and  retention  (Iriye,  2004). 

The  Platform  and  Payload  Integration  Department  knowledge 
management  in  the  past  and  present  is  division  dependent.  Each  division  has  its 
own  process.  The  Missiles  Division  runs  a  comprehensive  KM  system  for  the 
Tomahawk  Missile  program  office  at  Naval  Air  Systems  Command  (NAVAIR), 
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which  is  their  primary  sponsor.  The  Launchers  Division  does  not  have  a  similar 
system  in  place.  Other  divisions  and  departments  run  other  KM  systems  at 
NUWC  Newport. 

2.  Present 

The  evaluation  of  the  present  was  conducted  to  understand  how  the 
existing  system  is  operating.  The  evaluation  of  Launchers  Division  knowledge 
management  consisted  of  problems  faced  and  existing  systems  used  in  the 
division.  It  included  a  similar  look  at  external  organizations.  The  outputs  of  this 
were  an  understanding  of  the  current  and  future  state  of  the  Launchers  Division. 

The  current  state  of  the  Launchers  Division  KM  system  has  several 
aspects  that  are  undesirable.  The  Launchers  Division  KM  system  functionality 
today  is  no  different  than  it  was  in  the  past.  In  addition  to  the  past  problems, 
there  are  Fleet  concerns  with  submarine  technical  support  and  data  calls  for  the 
Ohio  replacement  program.  There  appears  to  be  a  lack  of  communication 
between  the  Fleet  and  the  technical  community. 

The  analysis  of  the  present  state  included  an  evaluation  of  the  information 
technology  systems  that  retain  technical  data.  The  information  systems  used  to 
provide  technical  data  are  described  in  Table  1.  The  data  presented  in  Table  1 
was  generated  by  observing  available  databases  and  information  provided  from 
the  survey  conducted  (Appendix  A).  Each  of  the  systems  identified  perform  a 
function  and  provide  access  to  the  information  required  for  work  at  the  Launchers 
Division.  In  some  cases,  these  systems  are  hard  to  use  due  to  security 
requirements. 
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Table  1. 


Available  systems  to  the  Launchers  Division 


Name 

Description 

Naval  Marine 
Corps  Intranet 
(NMCI) 

Provider  of  hardware  and  software  for  the  Navy. 
Primary  information  technology  provider  for  the 
stakeholders  identified  in  this  chapter.  Has  specific 
software  and  hardware  that  are  approved  for  use.  If 
one  wants  to  add  software  it  has  to  be  certified. 

Research 
Development 
Test  and 
Evaluation 
Network 

TEAM 

Additional  storage  of  data  and  software  for  a  fee. 
Provides  unique  software  and  hardware  that  are  not 
available  from  NMCI.  It  is  primarily  used  for  design  and 
analysis  projects.  Not  all  users  have  access  to  the 
Network.  It  has  a  network  storage  capability  that  is 
available  to  all  users  for  file  sharing. 

Provides  financial  data  management.  Provides  means 
of  tracking  project  milestones  and  funding  allotted  to 
tasks. 

Enterprise 

Resource 

Management 

System 

NUWC 

Knowledge  Net 
(Intranet) 

Intended  to  be  Navy  wide.  Provides  Project 

Management  tools  including  milestones,  earned  value 
management  etc.  NAVSEA  is  implementing  it  in 
FY2010  and  NUWC  in  FY201 1 . 

Provides  a  link  to  the  technical  library  and  other 
technical  sites.  The  technical  library  provides 

specification  data.  Published  technical  reports.  It  also 
provides  links  to  outside  organizations  and  department 
Microsoft  SharePoint  sites. 

AT  IS 

Provides  comprehensive  list  of  ship  drawings  for  all 
classes  supported. 

CITIS 

Provides  a  means  of  communicating  sensitive 
information.  It  also  provides  ship  drawings  and  the 
deviations  related  to  them.  It  provides  shipbuilder 
baseline  test  procedures  and  the  completed/signed  test 
procedures.  It  also  contains  the  document  databank 
with  the  majority  of  letters  that  have  been  written  by 
Electric  Boat  Corporation. 

Code  4123 
Technician 
Homage 

Provides  technical  data.  It  includes  links  to  Joint  Fleet 
maintenance  manual,  Ship  Systems  Manuals,  and 
other  types  of  technical  data.  It  also  has  engineering 
inputs  into  problems  solved  but  this  function  is  not 
consistently  used. 
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Code  412 

Access 

Database 

Provides  date  information,  letter  serial  numbers,  and 
titles  of  letters.  It  does  not  have  a  data  repository  where 
division  letters  are  retained.  It  also  documents 
communications  between  the  In-service  Engineering 
Agent  and  outside  customers 

SIPRNET 

Provides  Classified  Processing  of  Data.  Provides 
information  on  ships  and  means  of  communication  via 
email. 

Code  40  Internal 
Network 

Provides  a  means  of  file  sharing  and  transfer  between 
internal  Code  40  employees  that  have  access  to  the 
network.  Recently  the  network  has  been  disconnected 
due  to  the  partition  between  NMCI  and  the  Research 
Development  Test  and  Evaluation  Network.  Many  of 
the  files  it  contained  are  inaccessible  or  hard  to  find  to 
most  users. 

Tomahawk 

Information 

System 

Currently  provides  technical  highlights  to  be  provided  to 
leadership.  These  are  entered  by  Code  40  Users. 
This  system  is  available  to  Fleet  and  contractor  users. 

It  serves  as  a  means  of  file  transfer.  It  also  provides 
system  status  and  logistics  data  to  external  customers. 

NAVY  ELAR 
System 

The  Electronic  Liaison  Action  Request  (ELAR)  system 
provides  in-service  requests  for  technical  resolution.  It 
allows  users  to  enter  technical  resolutions  into  its 
database. 

Microsoft  Excel 
Action  Tracking 
sheet 

The  tracking  sheet  is  to  track  incoming  technical 
correspondence  from  the  VIRGINIA  Class  Program 
Office.  It  provides  need  dates  and  basic  information  on 
the  technical  correspondence. 

Scanned  Data 

The  VIRGINIA  Class  scanned  technical  data  that  is  not 
accessible  to  all  users.  It  includes  technical  reports, 
answers  to  technical  correspondence,  and  design 
decisions. 

NUWC 

Technical 

Library 

This  includes  Information  Handling  Services,  which 
provides  specification  data.  If  provides  a  repository  for 
technical  reports  and  other  technical  data. 
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NAVSEA 

technical 

correspondence 

database 

The  NAVSEA  technical  correspondence  database 
provides  letters  that  have  been  issued  by  NAVSEA. 
There  are  many  issues  with  this  database.  First,  it  is 
hard  to  search.  Even  when  the  correspondence  exists 
it  is  hard  to  find.  Certain  users  understand  how  to  use 
it  and  are  somewhat  successful  in  using  it.  It  is  not 
accessible  to  Launchers  Division  personnel. 

SUBMEPP 

Homepage 

The  SUBMEPP  homepage  provides  the  Joint  Fleet 
Maintenance  Manual.  SUPMEPP  provides  other 

technical  data. 

TEAMWARE 

Internet-based  provider  of  file  sharing  and  work  tasking 
run  by  Naval  Surface  Warfare  Center  and  used  by 
NAVSEA  program  offices.  It  is  used  by  some  projects 
but  not  all  projects.  Data  stored  is  available  for  a 
certain  amount  of  time  and  then  is  removed  when  not 
used.  Access  is  by  hard  and  soft  key  encryption. 

Risk  Radar 

Code  40  database  for  managing  and  tracking  risks 
related  to  projects. 

The  scope  of  data  provided  by  the  systems  in  Table  1  is  too  large  for  a 
single  system  for  use  by  the  Launchers  Division.  This  is  due  to  the  scope,  cost, 
and  availability  of  information.  Some  of  the  systems  have  constantly  changing 
information  which  is  produced  or  maintained  by  other  organizations.  Maintaining 
information  that  is  under  the  cognizance  of  other  organizations  is  almost 
impossible  when  the  data  is  constantly  changing  and  is  large  in  volume.  Some  of 
the  information  and  the  software  in  these  systems  provided  by  other 
organizations  is  proprietary.  In  some  cases,  the  government  would  have  to  pay 
the  contractor  for  these  systems  and  this  is  undesirable  due  to  the  cost  of  the 
data. 

Table  1  shows  that  the  data  the  Launchers  Division  works  with  is  similar 
across  the  life  cycle  of  the  products  it  works  on.  This  includes  calculations, 
drawings,  drawing  changes,  manuals,  specifications,  and  technical 
correspondence.  This  shows  the  data  the  technical  community  works  on  is 
similar  and  can  be  standardized.  Standardization  of  data  allows  designers  of 
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new  systems  to  obtain  data  on  systemic  problems  on  previous  designs.  This 
would  make  the  internal  system  searchable  to  find  the  data  that  they  need  to 
improve  their  technical  product. 

AIMTC  and  TOMIS  are  continuously  evolving  to  meet  customer  needs  and 
DoD  security  requirements.  TOMIS  has  about  25  personnel  that  are  working  on 
it  with  a  3-5  million  dollar  budget  annually.  TOMIS  has  over  1100  active  users  at 
150+  sites.  It  currently  has  38  unique  modules  and  434  software  changes  were 
made  in  FY09  (Sujecki,  2010).  Both  the  AIMTC  and  TOMIS  systems  are 
required  to  be  up  to  date  with  Navy  Security  policies,  which  include  two  site 
registrations  and  cryptographic  log-on  technology. 

Evaluation  of  the  current  state  of  KM  provides  additional  insight  into  the 
KM  systems  at  NUWC  Newport.  NUWC  Division  Newport  departments  have 
different  levels  of  formality,  which  they  have  applied  to  knowledge  management. 
The  level  of  formality  varies  between  division  or  department,  or  even  work  group. 
The  Launchers  Division  at  NUWC  Newport  has  no  formal  process  for  knowledge 
management,  resulting  in  incomplete  information  and  knowledge  about  the 
systems  it  works  on.  The  generation  of  technical  documentation  should  be 
standardized  across  the  life  cycle.  Not  all  technical  documentation  can  be  stored 
on  one  system,  and  the  system  will  have  to  rely  on  outside  systems  to  obtain  the 
required  data.  The  system  will  be  more  cost  effective  and  up-to-date  for  the 
Launchers  Division  if  it  can  rely  on  outside  systems  to  provide  data.  Other 
divisions  and  departments  in  some  cases,  have  more  comprehensive  KM 
systems  in  place. 

3.  Desired  Future  State 

The  desired  future  state  provides  an  evaluation  of  where  the  divisions’ 
projects  will  be  in  the  future.  This  includes  status  of  current  and  future  programs. 
The  programs  include  the  Virginia  Class  Submarine,  Ohio  Class  Submarine  and 
Ohio  Replacement  Program,  existing  ISEA  programs,  and  Seawolf  and  Los 
Angeles  Class  Submarines. 
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The  first  Virginia  Class  Submarine  was  commissioned  in  2004,  at  a  cost  of 
approximately  2.8  billion  dollars  (Little,  2008).  It  is  planned  to  be  a  thirty-ship 
class.  The  life  cycle  of  the  Virginia  Class  is  33  years.  The  Block  III  Virginia 
Contract  builds  Virginia  Class  submarines  until  2018  (Little,  2008),  and  brings  the 
total  number  of  submarines  to  18.  The  number  and  life  cycle  of  the  Virginia  class 
requires  the  system  shall  support  Virginia  Class  submarines  and  the  Launchers 
Division  until  at  least  2050.  The  construction  and  total  ownership  costs  are 
continuously  being  reduced  through  design  and  construction  improvements.  The 
combination  of  ISEA  and  design  support  for  Virginia  Class  will  require  retention 
of  launchers  knowledge  until  2050. 

The  Ohio  Class  and  Ohio  class  replacement  program  will  require  support 
until  at  least  2030  and  beyond.  Initial  Operating  Capability  in  2029  of  the  Ohio 
class  replacement  program  corresponds  with  the  first  Ohio  class  ballistic  missile 
submarine  being  decommissioned  (O'Rourke,  2010).  The  Ohio  class  submarine 
is  the  United  States  Sea  Based  Nuclear  deterrent.  Application  of  technical 
lessons  learned  may  provide  the  opportunity  to  reduce  costs  and  improve  quality 
(Government  Accountability  Office,  1994)  of  the  Ohio  Replacement  Program. 
Lessons  learned  from  Virginia  and  previous  classes  are  important  to  prevent 
problems,  already  encountered  on  existing  and  new  designs. 

The  Los  Angeles  and  Seawolf  Class  Submarines  are  in  the  operational 
support  and  decommissioning  stages  of  their  life  cycles.  The  62  Los  Angeles 
Class  Submarines,  which  entered  service  between  1976  and  1996,  have  an 
approximate  33-year  life  cycle  and  will  be  continuously  retired  from  now  until 
2030  (O'Rourke,  2009).  The  Seawolf  class  consists  of  three  submarines 
commissioned  between  1996  and  2005,  will  also  be  retired  in  the  2020-2030 
timeframe  (O'Rourke,  2009).  Retention  of  the  knowledge  gained  from  support  of 
these  two  classes  is  important  for  reduction  of  costs  on  current  and  future 
programs. 

Centralized  retention  of  knowledge  is  important  for  future  support  of 

current  and  future  submarines.  It  supports  the  Navy  initiatives  by  providing 
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historical  technical  data  and  elimination  of  redundant  efforts.  Support  of  the 
submarine  launchers  systems  will  be  at  least  until  2050,  which  means  the 
knowledge  generated  has  to  survive  until  then.  This  shows  that  a  centralized 
technical  KM  system  is  better  than  a  stove-piped  KM  system. 

D.  KM  BEST  PRACTICES 

The  KM  best  practices  phase  reviews  literature  to  help  define  the  best 
architecture  description  for  the  Launchers  Division.  The  review  addresses  the 
knowledge  management  cycle  and  the  key  elements  of  a  KM  system  and  forms 
the  conceptual  basis  for  the  system.  The  key  elements  provide  the  fundamentals 
of  a  successful  system  based  on  literature  and  benchmarking  studies.  The 
combination  of  understanding  of  both  of  these  provides  KM  best  practices. 

The  steps  to  the  knowledge  management  cycle  are  knowledge  creation, 
sharing,  capture  and  application.  The  steps  in  the  cycle  are  shown  in  Figure  6. 
Knowledge  creation  is  where  the  product  knowledge  is  generated.  Knowledge 
capture  is  where  the  knowledge  is  “translated  into  objective  and  transferrable 
knowledge  or  explicit  knowledge”  (Nonaka,  2008).  Knowledge  sharing  is 
socialization  through  the  interested  parties.  Knowledge  application  is  use  of  the 
knowledge  in  the  applicable  situation.  The  KM  cycle  is  important  to  a  company 
because  “individuals’  personal  knowledge  transformed  into  organizational 
knowledge  is  valuable  to  the  company  as  a  whole”  (Nonaka,  2008). 
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The  knowledge  management  cycle  shows  the  continuous  cycle  of  knowledge  creation, 
capture,  sharing  and  application.  The  continuous  cycle  is  intended  to  build  on  already 
known  information.  From  Love,  Irani,  &  Fong  (2004). 

There  are  two  types  of  knowledge:  tacit  and  explicit.  Explicit  information  is 
easily  written  and  codified.  Tacit  information  is  highly  personal  and  hard  to 
formalize,  which  makes  it  difficult  to  communicate  (Nonaka,  2008).  Tacit 
knowledge  is  partly  technical  know-how,  such  as  the  skills  of  a  master  craftsman, 
which  are  informal  skills  and  are  hard  to  replicate  (Nonaka,  2008).  “It  consists  of 
mental  models,  beliefs,  and  perspectives  so  ingrained  that  we  take  them  for 
granted  and  therefore  cannot  easily  articulate  them”  (Nonaka,  2008). 
Transformation  of  tacit  to  explicit  knowledge  and  back  are  important  parts  of  the 
knowledge  management  cycle. 
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The  key  elements  of  a  KM  system  are  people,  processes,  and  culture, 
with  technology  being  the  enabler  (Love,  Irani,  &  Fong,  2004).  There  is  a 
perception  that  information  technology  software  is  the  most  important  part  of  the 
solution.  It  is  not.  Eighty  percent  of  KM  is  people,  process,  culture,  and  the  other 
20  percent  is  technology  (Liebowitz,  1999).  The  American  Productivity  and 
Quality  Centers  Benchmarking  Study  (2000)  also  identified  people,  process, 
culture,  and  technology  as  key  factors  in  a  successful  KM  system.  The  specific 
factors  the  benchmarking  study  identified  are  the  following:  senior  champion  or 
management  endorsement,  budget,  communities  of  practice,  culture,  and 
information  technology  are  key  to  successful  implementation  of  a  KM  system. 
The  American  Productivity  and  Quality  Centers  Benchmarking  Study  (2000)  is 
based  on  a  survey  of  49  companies,  10  of  which  were  identified  as  having  strong 
KM  initiatives  in  place. 

Chan  (2002)  evaluated  the  NUWC  Submarine  Electromagnetic 
department  KM  practices.  The  Submarine  Electromagnetic  department  performs 
a  similar  ISEA  role  to  the  Launchers  Division.  Chan’s  work  was  based  on  loss  of 
tacit  knowledge  due  to  employee  attrition  through  workforce  retirements.  Chan 
(2002)  suggested  using  a  systematic  approach  to  the  development  of  a  KM 
system  through  understanding  of  the  organization’s  core  competencies.  One  of 
the  benefits  of  KM  is  it  leverages  the  intellectual  capital  of  the  entire  organization, 
“instead  of  working  as  individuals  is  the  only  way  to  gain  a  competitive 
advantage”  (Chan,  2002).  Chan’s  work  provides  the  following  conclusion: 

Firstly,  for  knowledge  management  to  succeed,  an  organization 
must  articulate  its  strategic  business  needs,  create  a  common 
framework  for  understanding,  secure  employee  buy-in,  and 
maintain  open  communications.  Secondly,  an  optimal  knowledge 
management  system  design  must  take  into  account  the  user's 
perspective  since  efficient  knowledge  flow  and  knowledge 
transformations  depend  on  people's  willing  participation,  (p.  94) 

The  NAVSEA  ship  design  department  identified  its  inability  to  find 
documentation  through  a  NSWC-funded  study  (Junod,  Read,  &  Kaistha,  2007). 

The  study  had  clear  requirements  and  provided  potential  technical  solutions.  It 
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focused  on  the  knowledge  cycle  presented  in  Figure  6  to  share,  create,  and 
apply  the  knowledge  to  create  innovative  surface  ship  designs.  The 
documentation  needed  to  create  surface  ship  designs  was  difficult  to  find  even 
though  it  was  stored  on  the  network  drives,  which  is  a  similar  situation  the 
Launchers  Division  faces. 

This  section  provides  KM  best  practices  for  a  successful  system.  These 
practices  include  the  knowledge  management  cycle  and  key  success  factors  for 
a  KM  system.  Understanding  of  the  knowledge  management  cycle  (Figure  6), 
and  how  knowledge  is  generated  is  important  for  understanding  knowledge 
management.  The  transfer  of  tacit  to  explicit  knowledge  is  an  important  part  of 
the  knowledge  transfer  process.  An  improved  KM  system  should  incorporate  key 
factors  for  success,  which  include  a  senior  champion  or  management 
endorsement,  budget,  communities  of  practice,  culture,  and  information 
technology.  A  better  solution  is  based  on  stakeholder  inputs. 

E.  SYNTHESIS  OF  RESULTS 

The  synthesis  of  results  phase  creates  the  top-level  requirements  for  the 
system.  This  is  done  by  combining  the  outputs  of  the  stakeholder  identification 
and  needs,  situational  assessment,  and  KM  best  practices  outputs.  Each  of  the 
outputs  is  solution-neutral  and  provides  problem  definition. 

Each  of  the  assessments  in  Parts  B,  C,  and  D,  and  the  follow-on  chapters, 
have  led  to  the  top-level  requirements. 

o  The  KM  system  shall  provide  a  data  repository  to  capture  and 
communicate  technical  knowledge  for  all  aspects  of  the  lifecycle  of 
Undersea  Launcher  Systems  from  development  to  disposal. 

o  The  KM  systems  implementation  shall  be  based  on  culture  change, 
having  a  senior  champion,  incentives  for  use,  and  available  budget. 

o  The  KM  system  shall  perform  the  following  functions:  store 
technical  data,  generate  knowledge,  analyze  the  number  of 
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documents  input  to  and  output  by  the  system,  recognize  recurrent 
technical  problems,  handle  classified  information,  organize, 
retrieve,  and  report  internal  and  external  data. 

■  Data  includes  letters,  calculations,  technical  data  packages, 
calculations,  analysis  files,  drawing  files,  waivers,  departures 
from  specification,  and  deviations,  technical  manuals,  and 
maintenance  data.  The  system  shall  support  at  a  minimum 
storage  of  Microsoft  Office  documentation,  Adobe®  PDF 
formats,  and  viewing  file  formats  (i.e.,  .jpeg,  .tiff). 

o  The  KM  system  shall  generate  knowledge-based  knowledge 
creation  cycle  (Figure  6). 

o  The  KM  system  shall  be  easily  searchable  by  internal  and  external 
personnel  to  the  Launchers  Division.  Internal  personnel  include 
people  who  are  employees  of  the  Launchers  Division.  External 
personnel  include  technical  warrant  holders,  program  office,  and 
Fleet  personnel.  “Easily  searchable”  means  document  lists  are 
returned  within  a  minute  of  query,  and  the  user  interface  is  easy  to 
read. 

o  The  data  generated  shall  last  30  years  and  a  means  of  backing  up 
the  data  shall  be  included. 

o  The  KM  system  shall  be  a  system  of  systems  and  use  data  from 
available  systems.  The  processes  generated  can  use  legacy 
systems.  The  system  shall  not  replace  outside  organizations’ 
systems.  These  include  Table  2  (CITIS,  ATIS,  ELAR)  and  other 
systems. 

o  The  KM  system  shall  be  available  to  NAVSEA,  the  Fleet,  and 
contractors. 
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o  The  KM  system  shall  provide  a  method  of  translation  of  tacit  to 
explicit  knowledge,  and  back. 

o  The  KM  system  shall  comply  with  all  of  the  DoD  information 
security  requirements. 

o  The  KM  system  shall  be  able  to  operate  on  the  Naval  Marine  Corps 
Intranet. 

F.  CHAPTER  SUMMARY 

The  top-level  requirements  generated  in  this  chapter  were  analyzed  and 
refined  into  system  requirements,  which  was  the  first  step  in  generation  of  the 
systems  architecture.  The  initial  stakeholder  analysis  and  situational  assessment 
were  performed  to  analyze  who  the  stakeholders  are,  the  past  and  current  state 
of  affairs,  and  a  study  on  the  current  state  of  knowledge  management.  A  KM 
best  practices  review  was  also  conducted.  The  combination  of  the  three 
processes  led  to  the  synthesis  of  top-level  requirements  and  definition  of 
stakeholders. 

The  surveys,  situational  assessment,  and  literature  research  indicate  that 
a  comprehensive  technical  KM  system  is  better  than  a  stove-piped  KM  system. 
This  allows  the  life-cycle  needs  of  the  Launchers  Division  to  be  met.  The 
technical  documentation  needed  for  the  Launchers  Division  across  the  life  cycle 
is  similar  from  design  to  operational  support,  allowing  for  creation  of  a 
comprehensive  system.  The  system  will  be  more  cost  effective,  and  up-to-date, 
if  it  relies  on  already  existing  external  KM  systems  to  provide  technical  data.  KM 
requirements  and  funding  are  changing  constantly;  a  system  that  can  change  is 
better  than  a  system  that  cannot  change.  For  the  system  to  have  the  potential  to 
be  optimal,  or  the  best,  it  has  to  be  developed  based  on  stakeholders’  needs. 
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III.  REQUIREMENTS  DEVELOPMENT 


A.  INTRODUCTION 


The  process  used  in  this  chapter  translates  the  top-level  requirements  into 
derived  requirements.  Figure  7  shows  this  process.  It  is  broken  into  two 
sections:  functional  analysis  and  requirements  generation.  The  outputs  of  this 
chapter  are  derived  or  detailed  requirements  and  a  functional  hierarchy. 


Stakeholders  Defined 


Boundary  Definition 


Top  Level 
Requirements 


Functional 
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Functions 

Requirements 
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Functional  Heirarchy 
- ► 

Functional  Flow 
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Figure  7.  Requirements  Development  Process 


The  development  process  consists  of  two  steps.  The  two  steps  create  part  of  the 
functional  architecture  and  generate  requirements. 


The  functional  analysis  has  three  primary  steps:  generation  of  functions, 
creation  of  a  functional  hierarchy  and  functional  flow  block  diagrams.  A 
functional  analysis  is  an  iterative  process  of  translating  requirements  into  detailed 
design  criteria  (Blanchard  &  Fabrycky,  2006).  Functions  are  generated  from  the 
top-level  requirements.  “A  function  is  a  definite  purposeful  action  that  a  system 
must  accomplish  to  achieve  one  of  the  systems  objectives”  (Sage  &  Armstrong, 
2000).  The  functions  are  then  placed  into  a  functional  decomposition.  The 
purpose  of  the  functional  decomposition  is  to  break  the  needs  into  smaller  pieces. 
The  functional  flow  block  diagrams  describe  the  system  and  its  elements  in 
functional  terms  (Blanchard  &  Fabrycky,  2006).  Each  of  these  analyses  help  with 
further  definition  of  the  problem  and  generation  of  requirements. 

The  requirements  generation  process  results  in  the  derived  requirements 
for  the  system.  It  starts  with  an  evaluation  of  functions  followed  by  creation  of  a 
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functional  hierarchy,  functional  flow  block  diagrams,  and  writing  a  requirement  for 
each  of  the  functions.  The  requirements  are  written  so  they  are  traceable  to  the 
higher-level  functions  and  top-level  requirements. 

B.  FUNCTIONAL  ANALYSIS 

Functional  analysis  includes  creation  of  functions,  organizing  them  into  a 
functional  hierarchy,  and  creation  of  functional  flow  block  diagrams.  Each  of 
these  steps  helps  develop  the  problem.  The  outputs  of  this  phase  are  functions, 
functional  flow  block  diagrams,  and  a  functional  hierarchy. 

The  functions  are  created  by  translating  the  top-level  requirements  into  a 
listing  of  the  actions  the  system  is  expected  to  perform.  The  first  step  was  to  list 
all  of  the  functions  the  system  is  to  perform  within  the  boundaries  and  top-level 
requirements  identified.  An  example  of  an  action  by  the  system  is  to  collect  data. 
Generation  of  data  represents  creation  of  the  data  that  is  used  in  the  systems. 
Additional  functions  were  added  with  generation  of  the  functional  hierarchy  and 
the  functional  flow  block  diagrams. 

The  functions  include  generate  data,  collect  data,  input  data,  store  data, 
analyze  data,  report  data,  and  share  knowledge.  The  input  data  function  follows 
data  collection  (described  above).  It  is  used  to  partition  data  prior  to  storage  to 
ensure  that  it  can  be  found  and  it  is  sent  to  the  correct  area  for  classification. 
The  data  storage  function  is  to  keep  the  data  until  it  is  used.  Analyze  data 
provides  statistics  on  use  and  launcher  system  health  status.  Data  reporting 
provides  the  data  requested  by  users  and  reports  generated  by  the  system. 

The  functions  are  arranged  into  a  functional  hierarchy,  which  shows  the 
system  function  as  a  whole.  The  functional  hierarchy  with  numbering  is  shown  in 
Figure  8.  It  has  two  levels  and  can  be  decomposed  further  when  the  system  is 
further  defined.  The  functional  hierarchy  was  also  compared  to  the  top-level 
requirements  to  ensure  that  it  meets  their  intent.  In  a  of  couple  cases,  the 
hierarchy  was  modified  to  ensure  the  top-level  requirements’  intent  was  met. 
Additional  functions  were  added  after  the  functional  flow  block  diagram  was 
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created  and  the  functional  hierarchy  was  developed.  The  functional  hierarchy  is 
considered  to  be  the  functional  architecture  by  Buede  (2009). 


Figure  8.  Functional  Hierarchy. 

The  functional  hierarchy  further  defines  the  system.  It  consists  of  six  functions  and  their 
sub  functions. 

Following  the  creation  of  the  functional  hierarchy,  a  functional  flow  block 
diagram  was  created  for  the  system.  The  system  functional  flow  block  diagram  is 
shown  in  Figure  9.  It  provides  a  more  detailed  understanding  of  the  functions 
and  the  interactions  between  the  functions.  The  creation  of  the  functional  flow 
block  diagram  results  in  the  addition  of  knowledge  sharing  to  facilitate  the 
transfer  of  knowledge  between  individuals  and  organizations.  It  also  provides  an 
overview  of  how  the  system  functions. 


Figure  9.  Functional  Flow  Block  Diagram 


The  functional  flow  block  diagram  shows  the  continuous  flow  of  information.  It  provided 
insight  into  interactions  between  the  functions  of  the  system. 
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Generation  of  functions,  creation  of  a  functional  hierarchy,  and  the 
functional  flow  block  diagrams  allow  system  requirements  generation.  The 
functions  provide  the  actions.  The  functional  hierarchy  partitions  the  system  into 
smaller  parts  and  allows  traceability  to  the  top-level  requirements.  The  functional 
flow  block  diagrams  provide  a  view  of  the  interactions  between  the  functions. 
Each  step  of  the  process  results  in  further  definition  of  the  problem  and  feeds  into 
generation  of  requirements. 

C.  REQUIREMENTS  GENERATION 

The  requirements  generation  process  translates  the  problem  definition, 
top-level  requirements,  and  the  functional  analysis  into  more  specific  system 
requirements.  Requirements  generation  analyzes  each  function,  resulting  in 
requirements  for  each  function.  Verification  and  validation  steps  were  added  to 
ensure  the  written  requirements  were  testable.  This  section  also  required 
considerable  iterations  to  the  current  and  previous  phase  for  a  variety  of  reasons. 
The  output  of  this  phase  is  a  list  of  system  requirements. 

The  requirements  generation  process  used  is  iterative  and  consists  of 
multiple  steps.  The  first  step  was  writing  specific  requirements  for  each  function. 
Then,  the  requirements  were  evaluated  to  see  if  they  could  be  verified  and 
validated.  The  requirements  were  then  refined  following  the  addition  of  the 
verification  and  validation  of  the  requirements.  The  use  of  the  process  resulted 
in  a  refined  set  of  requirements. 

Verification  and  validation  of  the  requirements  is  important  to  ensure  they 
meet  the  intent  of  the  individual  and  system  requirements.  Verification  is  to 
ensure  the  elements  of  the  system  meet  their  individual  requirements  (Buede, 
2009).  Validation  ensures  that  the  system  meets  all  requirements  specified  by 
the  customer  (Blanchard  &  Fabrycky,  2006).  Verification  and  validation  in  this 
section  are  broken  into  test,  inspection,  analysis,  and  demonstration.  Some  of 
the  requirements  had  to  be  modified.  For  example,  the  requirement  “the  data 
shall  be  searchable”  did  not  define  what  data.  The  requirement  was  rewritten  to: 
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all  documentation  contained  within  the  system  (shall  be  searchable).  Other 
requirements  were  either  removed  or  reworded  to  make  them  verifiable. 

The  requirements  are  set  up  in  a  table  that  provides  traceability  from  the 
top-level  to  the  derived  requirements.  This  table  includes  the  tie  of  the  derived 
requirements  to  the  functional  hierarchy  and  top-level  requirements.  Each  of  the 
functions  in  the  functional  hierarchy  has  been  numbered  and  individual 
requirements  are  numbered  with  a  “KM”  and  the  number  corresponding  to  the 
functional  hierarchy.  The  requirements  matrix  is  provided  in  Table  2. 
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Table  2. 


Requirements  matrix 


Function 

Requirement 

System  Requirement 

Validation/Verification 

Number 

Number 

Test 

Inspection 

Analysis 

Demonstration 

1.0 

KM1.0 

The  system  shall  be  able  to  generate 
data.  Generation  of  data  includes 
facilitation  of  the  Figure  6  knowledge 
cycle.  This  includes  standard  templates 
for  generation  of  letters,  calculations,  and 
drawings. 

X 

1.1 

KM1.1 

The  system  shall  be  able  to  create  data. 
This  includes  standard  templates  for 
generation  of  letters,  calculations,  and 
drawings. 

X 

1.2 

KM1.2 

The  system  shall  be  able  to  assist  in 
translation  of  tacit  to  explicit  data.  This 
shall  include  shadowing  of  experts  to 
understand  how  the  task  is  completed. 
Followed  by  translation  of  the  tacit 
knowledge  by  changing  it  into  a  form  that 
can  be  used  by  others.  Other  methods 
can  be  used  to  accomplish  this  task. 

X 

2.0 

KM2.0 

The  system  shall  provide  the  ability  to 
input  data.  This  includes  data  that  is 
generated  on  Naval  Marine  Corps  Intranet 
and  external  to  the  Naval  Marine  Corps 
Intranet. 

X 

2.1 

KM2.1 

The  data  shall  be  able  to  be  entered  by  all 
users.  Users  include  Launchers  Division 
personnel,  NAVSEA  headquarters 
employees,  and  Fleet  Personnel  with 
access  to  NMCI. 

X 
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Function 

Requirement 

System  Requirement 

Vaiidation/Verification 

Number 

Number 

Test 

Inspection 

Analysis 

Demonstration 

2.2 

KM2.2 

The  system  shall  have  the  ability  to  sort 
data  by  system  and  project.  Systems 
include  torpedo  tube,  weapon  shipping 
and  handling,  internal  countermeasure 
launcher,  external  and  internal 
countermeasure  launchers,  trash  disposal 
unit,  surface  vessel  torpedo  tubes, 
weapon  shipping  and  handling,  and 
vertical  launch  systems.  The  system  shall 
include  the  ability  to  sort  data  by  project. 

X 

3.0 

KM3.0 

The  system  shall  provide  the  ability  to 
store  data. 

X 

3.0 

KM3.1 

The  system  shall  store  technical 
documentation.  Technical  documentation 
includes  letters,  calculations,  liaison 
action  requests,  drawings  and  can  be 
expanded  to  other  documents. 

X 

3.0 

KM3.2 

The  data  storage  capability  shall  be 
expandable  to  meet  the  needs  of  the 
division. 

X 

4.0 

KM4.0 

The  system  shall  provide  the  ability  to 
analyze  data.  Analysis  includes  input  and 
output  metrics.  Analysis  includes 
identification  of  system  issues  (the  second 
part  can  be  a  follow  on  capability) 

X 

4.1 

KM4.1 

The  system  shall  be  able  to  analyze 
launcher  system  data.  This  function  shall 
be  performed  by  launchers  personnel  or  a 
software  program. 

X 

X 

4.2 

KM4.2 

The  system  shall  provide  input  and  output 
metrics.  This  is  the  number  and  size  of 
documents  handled  by  this  system. 

X 

X 

5.0 

KM5.0 

The  system  shall  provide  the  ability  to 
report  data.  This  includes  providing  data 

X 
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Function 

Requirement 

System  Requirement 

Validation/Verification 

Number 

Number 

Test 

Inspection 

Analysis 

Demonstration 

files  that  are  contained  within  the  system. 

5.1 

KM5.1 

The  system  shall  be  able  to  be  searchable 
for  all  documentation  contained  within  the 

X 

system. 

5.2 

KM5.2 

The  system  shall  be  able  to  provide  data 
files  that  are  contained  within  it.  Different 
levels  of  access  shall  be  used  depending 
on  the  project  and  classification. 

X 

KM  5.3 

Data  reporting  is  providing  the  data  to  the 
users.  The  data  shall  include  reports 
generated,  letters,  white  papers,  and 
other  technical  correspondence  that  is 
contained  within  the  system. 

X 

6.0 

KM6.0 

The  system  shall  facilitate  knowledge 
sharing.  Knowledge  sharing  is  passing 
information  between  individuals  and 
organizations. 

X 

6.1 

KM6.1 

The  system  shall  facilitate  transfer  of 
knowledge  between  individuals.  Transfer 
of  knowledge  shall  be  accomplished 
through  multiple  forms  of  communication. 
The  forms  of  communication  shall  include 
written  and  oral. 

X 

6.2 

KM6.2 

The  system  shall  be  capable  of  sharing 
knowledge  to  organizations  which 
includes  NAVSEA,  ONR,  the  Fleet,  and 
contractors  of  the  Launchers  Division. 

KM7.0 

The  system  shall  have  the  ability  to  meet 
the  Department  of  Defense  information 
assurance  security  requirements. 

X 

KM7.1 

The  system  shall  be  adapted  to  meet 
security  requirements.  The  data  stored 
includes  Secret,  Confidential,  Distribution 

X 
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Function 

Number 

Requirement 

Number 

System  Requirement 

D,  NOFORN.  For  Official  Use  Only,  and 
other  classified  data. 

KM8.0 

The  system  shall  be  able  to  adapt  to  new 
requirements  and  functionality. 

KM9.0 

The  user  interfaces  shall  be  similar  to 
ones  that  are  already  used  such  as 
common  internet  search  engines, 
common  data  reporting  similar  to  formats 
used  in  the  Division. 

KM10.0 

The  system  shall  last  30  years 

KM11.0 

The  system  shall  have  back  up  data 
storage,  processing,  and  power  supplies. 

KM12.0 

The  system  shall  be  compatible  with  the 
Naval  Marine  Corps  Intranet. 

KM13.0 

The  system  shall  be  based  on  KM  best 
practices  that  include  a  Management 
Champion,  Community  of  Practice, 
Technology,  and  Processes. 
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Validation/Verification 

Test  Inspection  Analysis  Demonstration 


X 

X 

X 

X 

X 

X 

X 

The  requirements  were  further  refined  as  the  architecture  was  developed 
and  will  be  further  defined  when  the  detail  system  design  is  defined.  The  detail 
system  will  not  be  defined  in  this  thesis.  Table  2  was  a  result  of  the  requirements 
development  process. 

D.  CHAPTER  SUMMARY 

The  derived  requirements  are  created  from  the  top-level  requirements. 
The  process  of  deriving  the  requirements  includes  a  functional  analysis.  The 
functional  analysis  consists  of  generation  of  functions,  creation  of  functional 
hierarchy  and  functional  flow  block  diagrams.  The  result  is  more  detailed 
requirements.  The  more  detailed  requirements  and  functional  hierarchy  allow  for 
development  of  the  architecture  description. 
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IV.  ARCHITECTURE  DEVELOPMENT 


A.  INTRODUCTION 

The  process  for  the  architecture  description  development  is  described  in 
this  chapter.  It  continues  the  systems  engineering  process  to  create  the  best 
architecture  description  when  evaluated  against  the  other  concepts.  The  process 
consists  of  functional  architecture  development,  concept  generation,  and 
aggregation  and  evaluation  of  concepts  to  satisfy  the  requirements.  The  concept 
generation  process  translates  the  requirements  into  concepts.  The  concepts  are 
aggregated  into  a  high-level  architecture  description  and  evaluated. 

The  high-level  architecture  description  created  is  based  on  Maier  and 
Rechtin  (2000),  and  the  Institute  of  Electrical  and  Electronic  Engineers,  (2000). 
Both  recommend  that  the  description  used  is  unique  to  the  problem  and  the 
subject  of  the  problem.  The  high-level  architecture  means  integration  of  the 
components  at  the  upper  levels  of  the  system  (Maier  &  Rechtin,  2000).  The 
architecture  description  consists  of  the  purpose  of  the  system,  the  stakeholders, 
the  requirements,  and  architectural  viewpoints.  The  architecture  description  is 
created  in  response  to  the  “current  stakeholder  needs  using  current  and 
estimated  technological  capabilities”  (Institute  of  Electrical  and  Electronic 
Engineers,  2000). 

B.  FUNCTIONAL  ARCHITECTURE 

The  functional  architecture  development  continues  the  development  of  a 
KM  system.  The  Figure  8  functional  hierarchy  and  Figure  9  functional  flow  block 
diagram  combined  with  an  external  systems  diagram  are  the  high-level  functional 
architecture.  This  section  provides  an  external  systems  diagram  and  functional 
viewpoints  to  form  the  functional  architecture. 

The  external  systems  diagram  shows  the  system  and  the  components  that 

interface  with  the  system,  which  is  provided  in  Figure  10.  These  systems  include 

the  classified  networks,  drawing  repositories,  manual  databases,  deviation  and 
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waiver  tracking  systems,  ships’  casualty  reports,  other  Navy  knowledge  sites, 
contractor  repositories,  and  NAVSEA  repositories.  The  external  systems  are 
defined  as  a  result  of  the  Table  1  systems  matrix  and  the  NUWC  employee 
survey  (results  detailed  in  Appendix  A).  The  findings  of  the  situational 
assessment  show  that  the  system  cannot  be  all-inclusive  due  to  the  scope  and 
constantly  changing  nature  of  the  data.  The  system  will  include  processes  and 
products  that  are  within  the  control  of  the  Launchers  Division. 


Figure  10.  External  systems  diagram 


The  external  systems  diagram  provides  the  interactions  between  the  system  and  external 
sources  of  information.  These  sources  of  information  are  either  too  large  or  constantly 
changing  to  keep  the  information  with  the  system. 

Each  of  the  external  systems  identified  in  Figure  10  interact  with  the 

Launchers  Division  KM  system.  The  CITIS  and  ATIS  drawing  repositories 
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provide  drawings  for  multiple  classes  of  submarines.  The  deviation  and  waiver 
tracking  systems  include  the  ELAR  systems  and  databases  that  contain  ships’ 
departure  from  specification  information.  There  are  multiple  sources  of 
maintenance  manuals  and  Web-based  electronic  maintenance  manual  access 
hosted  by  the  Submarine  Maintenance  Engineering  Planning  and  Procurement 
Activity  (SUBMEPP).  Ships’  casualty  reports  are  provided  by  SIPRNET  e-mails 
and  include  information  on  system  operation  problems  ships  encounter.  Other 
Navy  knowledge  sites  include  TEAMWARE,  which  provides  a  Navy-run 
collaboration  system.  The  TEAMWARE  system  allows  secure  transfer  of  files 
between  users  including  contractors  and  Fleet  personnel.  Contractors  also 
maintain  sites  similar  to  TEAMWARE,  and  databases  for  storage  of  technical 
correspondence.  The  contractors  who  run  the  ships’  planning  yards  provide 
ships’  technical  documentation  that  includes  drawings,  letters,  and  other  types  of 
technical  data.  The  NAVSEA  repositories  include  the  NUWC  Intranet  and 
NAVSEA  technical  correspondence  database. 

The  Launchers  Division  KM  system  functional  architecture  is  defined  in 
Figure  8  functional  hierarchy  and  Figure  9  functional  flow  block  diagram.  These 
figures  serve  as  the  basis  for  further  definition  of  the  functional  architecture.  The 
numbering  of  the  functional  viewpoints  corresponds  to  the  Figure  8  functional 
hierarchy,  which  ensures  the  flow  down  of  the  top-level  requirements.  Note  the 
viewpoints  that  further  define  the  functional  architecture  do  not  follow  IDEF  or  a 
functional  flow  block  diagram  languages,  because  they  do  not  support  the  intent 
of  the  architecture  description. 

The  Figure  1 1  generation  of  data  function  includes  creation  of  data  and 
transformation  into  useable  form.  It  is  a  decomposition  of  function  1.0  from 
Figure  8  and  Figure  9.  The  creation  of  data  function  shown  in  Figure  1 1  intends 
to  analyze  and  solve  Fleet  operational,  maintenance,  and  new  construction 
problems.  The  analysis  could  be  as  simple  as  providing  the  answer  to  a 
previously  answered  problem  or  a  material  issue  that  is  hard  to  solve  and  affects 
the  safe  operation  of  a  system.  Once  solved,  the  solution  to  the  problem  is 
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archived  for  future  use.  If  the  problem  cannot  be  solved  easily,  either  a  design 
solution  would  need  to  be  created  or  research  would  need  to  be  conducted  to 
find  a  solution  to  the  problem.  The  policies  for  creation  of  design  solutions  are 
the  Launchers  Divisions’  hardware  development  and  drawing  issue  policies.  The 
performance  of  research  creates  new  solutions  or  creates  new  ways  of  analyzing 
a  previously  unsolvable  problem.  The  drawing  policy  and  hardware  development 
policy  aid  in  transformation  of  an  idea  into  usable  form. 


System  Problem 


Figure  1 1 .  Generate  data 


This  figure  provides  a  viewpoint  of  the  generation  of  data  function.  The  process  includes 
creation  of  data  and  transformation  into  usable  form  functions. 

The  transformation  into  usable  form  function  also  includes  additional 
processes  for  creation  of  other  types  of  documentation.  The  other  types  of 
documentation  include  procedures  for  documentation  of  technical  analysis  and 
design  decisions;  this  includes  white  papers,  meeting  minutes,  and  letters.  The 
transformation  of  data  function  will  allow  technical  analysis  results  to  be 
documented  and  stored  for  future  use.  The  purpose  of  this  documentation  is  to 
record  the  details  and  methodology  used  so  they  can  be  understood  and/or 
recreated  to  solve  other  similar  problems. 

Input  of  data  takes  the  generated  data  and  prepares  it  for  storage.  Figure 
12  shows  how  data  is  entered  into  the  system  either  by  manual  or  automatic 
input.  It  is  a  decomposition  of  function  2.0  from  Figure  8  and  Figure  9.  Manual 
input  is  data  that  cannot  be  directly  entered  into  the  system.  It  includes  data  that 
needs  to  be  scanned,  or  is  not  in  a  format  that  is  recognized  by  the  system. 
Automatic  data  input  is  in  a  format  the  system  recognizes,  so  it  can  be  sorted  for 
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data  storage.  Data  sorting  can  be  accomplished  either  by  the  system  or 
manually  by  a  processor  or  by  the  user.  Data  sorting  can  sort  by  system  or 
project. 


Figure  12.  Input  data 

The  input  of  data  function  includes  data  that  is  not  electronic  or  in  a  form  that  cannot  be 
input.  It  also  sorts  data  for  storage. 

Data  storage  and  retention  functions  are  intended  to  file  the  data  until  it  is 
needed.  Figure  13  shows  the  storage  of  the  data,  including  divisions  of  files  by 
system.  It  is  a  decomposition  of  function  3.0  from  Figure  8  and  Figure  9.  It  also 
shows  classified  data  in  a  separate  repository.  The  separate  repositories  include 
Naval  Nuclear  Propulsion  Information  (NNPI)  and  classified  information  up  to  the 
Secret  level.  The  use  of  data  types  X,  Y,  and  Z  are  to  show  that  the  database 
can  be  separated  by  system  or  project.  For  example,  data  type  X  could  be  used 
to  store  data  for  torpedo  tubes  and  data  type  Y  could  store  data  for  the  Virginia 
Class  Project.  The  development  and  operation  of  the  repositories  will  have  to 
follow  DoD  and  NUWC  policy  for  storage  of  all  types  of  information.  The 
intention  is  to  store  the  data  for  at  least  30  years,  which  corresponds  to  the  life 
cycle  of  a  ship.  This  means  that  the  system  will  have  to  store  the  data  and  be 
able  to  read  the  data  when  some  of  the  current  software  and  hardware  may  be 
obsolete  and  the  file  format  may  be  unable  to  be  read.  It  is  hard  to  plan  for  what 
is  going  to  happen  in  the  future  and  that  is  why  the  system  needs  to  be  flexible  to 
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change  while  retaining  the  ability  to  provide  the  data  from  older  file  formats. 
Each  file  type  stored  may  have  to  be  evaluated  as  the  systems  change,  and  the 
software  and  associated  operating  systems  may  have  to  be  kept  to  read  the 
older  files. 


Figure  13.  Store  data 


The  store  data  shows  the  parsing  of  data.  It  includes  partition  of  classified  data  and 
unclassified  data.  The  data  types  X,  Y,  and  Z  represent  the  different  systems  that  the 
Launchers  Division  works  on. 

Figure  14  analyzes  data,  which  tracks  system  usage  and  analyzes  the 
recurrence  of  launcher  system  problems.  It  is  a  decomposition  of  function  4.0 
from  Figure  8  and  Figure  9.  The  count  numbers  of  documents'  input  and  output 
function  is  intended  to  determine  the  effectiveness  of  the  KM  system.  This 
allows  for  determination  of  weak  areas  of  the  KM  system  operation.  It  also 
provides  data  on  the  usage  and  cost  of  the  system  to  justify  budgets.  The  other 
area  of  analysis  is  problems  with  launchers  systems.  The  function  is  intended  to 
identify  systemic  technical  problems  and  understand  the  technical  status  of  the 
systems  under  the  cognizance  of  the  Launchers  Division.  If  the  same  problem 
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shows  up  multiple  times,  it  could  be  identified  as  a  potential  systemic  problem 
rather  than  operator  error.  The  problem  areas  identified  are  communicated  to 
the  sponsors  for  consideration  of  funding  to  resolve  the  issue.  These  areas  also 
provide  lessons  learned  for  development  of  future  platforms,  such  as  the  Ohio 
Replacement  Program. 


Figure  14.  Analyze  data 


The  figure  includes  two  distinct  processes.  One  is  for  monitoring  KM  system  use  and  the 
other  is  monitoring  the  status  of  Launcher  systems. 

The  data  reporting  function  is  searching  and  providing  the  data  to  the 
system  users.  Figure  15  shows  data  search,  selection,  and  processing  of  the 
data  request.  It  is  a  decomposition  of  function  5.0  from  Figure  8  and  Figure  9. 
The  system  search  will  include  a  search  capability  that  is  familiar  to  the  users 
such  as  Google  or  Wiki.  The  system  will  provide  the  candidate  documents  for 
selection  of  the  needed  document  or  database.  The  user  selects  the  data  and 
the  system  will  provide  the  data  to  the  user.  This  function  primarily  would  be 
accomplished  by  system  software  or  a  filing  system. 
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Figure  15.  Report  data 


The  report  data  function  includes  searching  for  the  data  the  user  is  looking  for.  Then 
selecting  the  information  the  search  provides  and  then  the  system  provides  the 
information  to  the  user. 

Figure  16  provides  the  knowledge  sharing  function.  It  is  a  decomposition 
of  function  6.0  from  Figure  8  and  Figure  9.  The  function  is  based  on  interaction 
between  individuals  within  the  organization  and  outside  of  the  organization.  The 
first  step  in  the  process  is  the  request  of  knowledge  between  employees  of  the 
Launchers  Division  or  between  Launchers  Division  employees  and  either  the 
Fleet,  NAVSEA,  or  contractors.  The  interaction  can  be  as  formal  as  meetings  or 
as  informal  as  phone  conversations.  Once  the  knowledge  is  communicated,  the 
individual  has  to  synthesize  and  understand  the  knowledge  so  that  it  can  be 
applied.  The  interactions  between  the  individuals  are  intended  to  reach  a  shared 
understanding  of  the  issues  at  hand,  the  methodology  to  solve,  or  the  solution  to 
a  problem. 


Figure  16.  Share  knowledge 


The  sharing  knowledge  figure  provides  sharing  inside  and  outside  of  the  organization.  It 
also  provides  a  user  processing  the  data. 
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C.  CONCEPT  GENERATION 

Concepts  are  generated  following  the  functional  architecture  development. 
The  concept  generation  process  is  based  on  Ulrich  and  Eppinger  (2000)  and 
Buede  (2009).  Each  of  the  Table  2  functions  and  requirements  have  at  least  one 
concept  created  for  them.  The  concepts  are  also  consistent  with  the  functional 
architecture  created,  since  the  requirements  are  generated  from  the  functional 
heirarchy.  This  process  traces  the  concepts  to  the  problem  definition,  and  results 
in  changes  to  the  requirements. 

The  concept  creation  process  uses  the  morphological  box  technique 
described  in  Buede  (2009).  The  morpological  box  is  a  process  that  “divides  a 
problem  into  segments  and  posits  several  solutions  for  each  segment”  (Buede, 
2009).  The  list  of  ideas  or  concepts  is  generated  using  benchmarking  of  similar 
products,  suggestions  from  the  surveys,  analogy  to  other  systems,  imagination, 
and  searching  related  literature.  The  result  is  at  least  one  concept  for  each 
requirement. 

The  concepts  generated  are  described  in  detail  in  Appendix  B.  The  goal 
is  to  provide  multiple  concepts  for  each  requirement,  combining  some  of  them 
into  a  more  complex  system.  The  concepts  consist  of  people,  processes,  and 
information  technology.  They  range  from  adding  software  to  use  of  manual 
procedures.  The  software  and  hardware  solutions  include  commercial-off-the- 
shelf  (COTS)  products.  The  COTS  solutions  range  from  usage  of  wiki  software 
to  usage  of  Google  desktop,  which  provides  a  search  capability.  Some  of  the 
software  solutions  advertise  that  they  have  DoD  software  security  accreditations 
that  are  already  complete.  The  concepts  are  more  detailed  than  the  ones 
contained  in  a  high-level  architecture.  Generation  of  detailed  concepts  provides 
further  refinement  of  the  problem  definition  and  Table  2  requirements. 

The  concept  generation  process  results  in  changes  to  the  requirements 
and  functional  hierarchy.  The  original  system  requirements  did  not  include  the 
Naval  Marine  Corps  Intranet  (NMCI).  NMCI  is  the  primary  information 
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technology  system  used  by  the  stakeholders.  The  requirements  were  changed 
to  add,  “the  system  shall  function  on  the  NMCI  system.”  In  addition,  the  majority 
of  NMCI  users  have  hard  key  encryption,  which  allows  the  system  to  operate 
without  the  use  of  additional  soft  key  logon,  and  the  security  associated  with  it. 
NMCI  has  approved  hardware  and  software  for  use  on  NMCI  systems.  All  other 
software  has  to  be  designed  to  DoD  security  specifications  and  tested  to  the 
security  requirements  by  the  NMCI  administrator  at  a  cost.  In  addition,  the 
process  results  in  revision  of  the  functional  hierarchy.  The  revisions  remove  the 
collect  data  function  due  to  it  being  redundant  with  the  input  data  function. 

D.  CONCEPT  EVALUATION 

The  concepts  from  the  previous  section  were  aggregated  and  evaluated  to 
create  the  recommended  architecture.  Concept  aggregation  is  an  iterative 
process  that  combines  concepts  and  evaluates  them  as  a  whole.  The  evaluation 
results  in  selection  of  the  high-level  architecture.  The  evaluation  ensures  the 
stakeholder  requirements  are  met  by  using  the  requirements  as  the  evaluation 
criteria. 

Concept  aggregation  combines  the  concepts  generated  in  the  previous 
section.  The  combinations  of  hardware  and  software  solutions  include  COTS 
products,  existing  systems,  and  unique  software  developed  for  the  system.  The 
processes  and  incentives  are  identified  to  facilitate  system  use  and  meet 
requirements  the  information  technology  cannot  perform.  The  processes  consist 
of  ways  of  managing  the  system  and  generation  of  technical  documentation, 
including  calculations  and  correspondence.  The  concepts  are  based  on  a 
system  that  can  be  tailored  to  specific  needs,  including  further  definition  of 
system  capacities  and  functionalities.  Flexibility  of  the  high-level  architecture  will 
allow  the  system  to  be  changed  in  the  future. 

The  evaluation  of  the  architecture  concepts  consists  of  the  use  of  a 
scoring  matrix.  The  scoring  matrix  is  based  on  methodology  from  Ulrich  and 
Eppinger  (2000).  The  scoring  matrix  supports  the  decision-making  process  by 
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selecting  the  best  combination  of  hardware,  software,  procedures,  and  incentives 
to  form  the  high-level  architecture.  The  scoring  matrix  utilizes  the  requirements 
as  the  criteria.  The  requirements  used  are  KM1.0,  2.0,  3.0,  4.0,  and  5.0.  The 
concepts  were  given  values  between  1  and  5  (Table  3).  The  standard  is  the 
current  system:  by  definition,  it  is  assigned  a  score  of  3  for  all  attributes.  A  value 
less  than  3  means  the  architecture  concept  is  ranked  worse  than  the  standard.  A 
value  greater  than  3  means  the  architecture  concept  is  ranked  better  than  the 
standard.  Table  4  provides  the  scoring  results.  The  top  row  contains  the 
concepts  and  the  column  to  the  left  contains  the  requirements.  This  differs  from 
the  morphological  box  technique  by  combining  like  themes  or  similar  solution 
sets.  In  addition  to  the  core  requirements,  expected  development  cost  was 
added  to  the  scoring  matrix.  This  assumption  is  based  on  the  American 
Productivity  and  Quality  Center  (2000)  benchmarking  study  statement  that  yearly 
maintenance  costs  are  equivalent  to  system  start-up  costs. 

Table  3.  Scoring  criteria 


Scoring  Criteria 

Rating 

Much  Better  than  Standard 

5 

Better  than  Standard 

4 

Equal  to  Standard 

3 

Worse  than  Standard 

2 

Much  Worse  than  Standard 

1 

Table  4  represents  the  results  of  comparing  the  concepts  against  a 
baseline.  The  scores  in  Table  4  show  that  all  of  the  concepts  are  equal  to  or 
better  than  the  standard  with  respect  to  the  requirements.  All  alternatives  scored 
4  for  all  the  concepts  in  KM1.0  and  KM6.0  because  they  are  all  estimated  to  be 
better  than  the  baseline  by  about  the  same  amount.  The  alternatives  scored  3 
for  all  the  concepts  in  KM2.0  because  they  are  all  estimated  to  be  the  same  as 
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the  baseline,  which  may  change  when  the  systems  are  further  defined.  All 
alternatives  scored  either  3  or  4  for  KM3.0.  The  alternatives  with  scores  of  3  are 
estimated  to  have  the  same  storage  capability  as  the  existing  system.  The 
alternatives  with  scores  of  4  are  estimated  to  provide  additional  storage  capability. 
All  of  the  alternatives  for  both  KM4.0  and  KM5.0  have  scores  of  4  and  5.  The 
alternatives  with  rankings  of  4  for  KM4.0  and  KM5.0  are  estimated  to  have  more 
functionality  than  the  baseline. 

Cost  and  risk  were  added  to  Table  4  to  provide  additional  evaluation  of  the 
concepts.  All  of  the  alternatives  ranked  lower  that  the  baseline  due  to  their 
additional  cost  and  risk  for  development.  Development  of  any  of  the  alternatives 
will  include  additional  cost.  For  example,  development  policies  and  procedures 
will  require  funding  to  develop  them.  Once  developed,  there  is  a  risk  that  the 
stakeholders  may  not  agree  on  their  content  or  whether  they  are  needed. 
Increased  cost  and  risk  will  result  from  developing  software.  The  software  has  to 
be  coded  and  functional  before  it  can  be  used,  which  takes  time  and  money. 
There  is  a  risk  in  developing  the  software  because  it  may  not  function  properly 
and  or  provide  the  functionality  desired  by  the  user.  A  score  of  1  for  both  cost 
and  risk  was  estimated  for  the  alternative  that  develops  procedures  and  creates 
software  and  hardware.  The  remaining  alternatives  were  given  a  score  of  2 
when  compared  to  the  baseline. 
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Table  4.  Concept  scoring  matrix 


Function 

Number 

Requirement 

Number 

System  Requirement 

Use  Existing 
Hardware, 

Software  (Basic 
System),  Develop 
Procedures,  and 
Create  incentives 

Use  Existing 

Hardware, 

Develop 

Software, 

Develop 

Procedures, 

and  Create 

Incentives 

Buy  New 

Hardware, 

Develop 

Software, 

Develop 

Procedures, 

and  Create 

incentives 

Buy  New 

Hardware  and 

Software, 

Develop 

Procedures, 

and  Create 

incentives 

Use  Existing 

System 

(Benchmark) 

1.0 

KM1.0 

System  be  able  to 
generate  data.  This 
includes  generation  of 
letters,  calculations,  and 
drawings. 

4 

4 

4 

4 

3 

2.0 

KM2.0 

System  shall  provide  the 
ability  to  input  data. 

This  includes  data  that 
is  generated  on  Naval 
Marine  Corps  Intranet 
and  external  to  the 

Naval  Marine  Corps 
Intranet. 

3 

3 

3 

3 

3 

3.0 

KM3.0 

System  shall  provide  the 
ability  to  store  data. 

3 

3 

4 

4 

3 

4.0 

KM4.0 

System  shall  provide  the 
ability  to  analyze  data. 

4 

5 

5 

5 

3 

5.0 

KM5.0 

System  shall  provide  the 
ability  to  report  data. 

4 

5 

5 

5 

3 

6.0 

KM6.0 

The  system  shall 
facilitate  knowledge 
sharing 

4 

4 

4 

4 

3 

Expected  Cost 

2 

2 

1 

2 

3 

Development  Risk 

2 

2 

1 

2 

3 
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E.  RECOMMENDED  ARCHITECTURE 

The  alternative  selected  is  to  buy  new  hardware  and  software  and 
implement  procedures  and  incentives.  It  scored  similar  or  better  in  all  areas  than 
the  other  concepts.  The  associated  cost  and  risk  of  the  system  are  worth  the 
additional  functionality.  However,  this  assessment  may  change  as  funding  and 
requirements  are  further  defined  for  the  system. 

System  implementation  will  have  to  be  phased  to  change  the  overall  way 
knowledge  is  managed  in  the  Launchers  Division.  The  system  should  be 
sponsored  by  a  senior  manager  and  be  mandatory  for  the  employees  of  the 
Launchers  Division.  If  implemented,  the  recommended  architecture  will  have  to 
be  defined  further.  Part  of  this  definition  will  include  more  detailed  system 
capability,  functions,  and  capacities.  It  will  also  define  system  and  software 
specific  functionality. 

F.  CHAPTER  SUMMARY 

This  chapter  translates  the  requirements  generated  in  the  previous 
chapter  into  a  recommended  high-level  architecture.  It  accomplishes  this  by 
generating  concepts  to  meet  each  requirement  followed  by  aggregating  and 
evaluating  the  concepts  into  a  system.  The  recommended  architecture 
description  is  based  on  the  top-level  requirements,  functional  architecture,  and 
the  comparison  of  alternative  concepts. 
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V.  CONCLUSIONS 


A.  SUMMARY  AND  RECOMMENDATIONS 

As  a  result  of  this  study,  the  selected  architecture  description  is  based  on 
a  top  down  systems  engineering  process.  The  process  translates  the 
stakeholders’  inputs  and  KM  best  practices  into  the  problem  definition,  functional 
hierarchy,  and  requirements.  Translation  of  these  requirements  and  functions 
into  an  architecture  description  provides  a  better  way  to  implement  a  KM  system, 
a  better  way  to  manage  data  from  design  to  operational  support,  and  the  best 
architecture  relative  to  the  other  options  for  knowledge  management  for  the 
Launchers  Division  than  the  existing  system. 

What  is  the  best  high-level  architecture  description  for  the  technical 
KM  system?  The  best  high-level  architecture  is  the  concept  that  meets 
stakeholder  requirements  at  a  higher  level  of  effectiveness  within  cost  constraints. 
In  this  thesis,  the  alternative  selected  is  the  one  consisting  of  new  hardware  and 
software  combined  with  procedures  and  incentives.  It  scored  higher  across  all 
evaluation  criteria,  which  were  based  on  the  system  level  requirements  derived 
from  user  needs,  KM  best  practices,  and  well  defined  interfaces  with  external 
systems.  The  system  will  be  more  cost  effective  and  up-to-date  if  it  relies  on 
already  existing  external  KM  systems  to  provide  technical  data  due  to  volume  of 
information,  constantly  changing  information,  and  other  organizations  being 
tasked  to  manage  that  data. 

What  is  an  improved  way  to  manage  technical  data  ranging  from 
design  to  operational  support  for  the  Launchers  Division  at  NUWC?  This 
thesis  reveals  that  an  improved  system  for  management  of  technical  data 
ranging  from  design  to  operational  support  of  the  Launchers  Division  is  based  on 
multiple  factors.  These  factors  include  documentation,  the  scope  of  the  system, 
and  changing  requirements.  The  study  reveals  the  types  of  documentation  used 
are  similar  across  the  life  cycle  of  submarine  systems,  allowing  use  of  a 
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combined  system.  The  surveys,  situational  assessment,  and  literature  research 
indicate  that  a  comprehensive  technical  KM  system  is  better  than  the  stove-piped 
KM  system  in  place.  The  situational  assessment  reveals  that  a  system  that 
interfaces  with  external  systems  already  in  place  is  better  than  the  standalone 
system  currently  in  use.  The  creation  of  a  single  system  for  documentation  not 
already  covered  by  external  systems  would  improve  management  of  technical 
data  at  the  Launchers  Division. 

It  is  recommended  that  the  architecture  developed  for  the  Launchers 
Division  be  further  defined  in  order  to  create  a  KM  system.  The  details  of  the 
system  need  to  be  created  and  evaluated.  Implementation  will  depend  on 
available  funding  and  consistent  requirements.  It  is  recommended  that  the 
architecture  developed  will  be  used  as  the  basis  for  the  Launchers  Division  KM 
system. 

B.  AREAS  FOR  FURTHER  RESEARCH 

Future  study  into  knowledge  management  would  include  questions  on 
measurement  of  the  KM  system,  development  of  additional  techniques  for 
translation  of  tacit  to  explicit  information,  and  methods  of  implementation  and 
maintenance. 

How  do  you  measure  the  performance  of  a  KM  system?  It  is  difficult  to 
measure  a  system  that  has  human  interfaces  and  is  based  on  the  needs  of 
human  beings  that  are  constantly  changing.  Measuring  cost  of  the  system  and 
organization  performance  are  possible  methods.  The  questions  should  include 
how  do  you  measure  the  increase  of  human  performance  from  a  KM  system? 
How  do  you  measure  the  increase  in  organizational  performance? 

What  are  successful  methods  of  translation  of  tacit  to  explicit 
information?  Nonaka  (2008)  uses  the  creation  of  a  bread  maker  in  his  writing  as 
an  example  of  translating  tacit  information  into  explicit  information.  He 
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recommends  the  use  of  symbols  to  transfer  the  knowledge  into  explicit 
information.  Further  work  should  include  creation  of  methodology  for  translation 
of  information. 

What  is  an  improved  way  to  reduce  costs  to  implement  and  maintain 
a  technical  KM  system  in  an  organization  that  supports  all  aspects  of  the 
life  cycle?  Implementation  and  maintenance  of  a  technical  knowledge 
management  system  are  important  to  its  own  success.  The  American 
Productivity  and  Quality  Center  (2000)  states  that  a  successful  KM  system’s 
maintenance  costs  are  equivalent  or  greater  than  systems  start-up  costs.  Future 
research  would  include  a  study  into  methods  and  cost  of  implementation  and 
maintenance  of  a  KM  system. 
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APPENDIX  A:  NUWC  EMPLOYEE  SURVEY  RESULTS 


The  author  generated  and  delivered  a  survey  to  gain  a  better  insight  into 
the  stakeholders’  needs  with  regard  to  technical  data  generation  and 
management,  their  current  processes  and  procedures,  and  the  desired 
functionality  of  a  system  to  support  their  work.  The  survey  and  its  conduct  were 
approved  by  the  Naval  Postgraduate  School  Institutional  Review  Board  for 
protection  of  the  people  surveyed.  The  people  surveyed  include  Launchers 
Division  management,  Launchers  Division  engineers,  selected  customers,  and 
contractors.  The  responses  are  documented  in  Table  5. 

The  survey  was  generated  to  focus  on  the  Launchers  Division  KM  system. 
The  questions  were  written  to  understand  how  individuals  generate  data  on, 
understand  the  processes  and  procedures  in  place,  the  barriers  to  knowledge 
management  and  provide  insight  into  the  functionality  of  the  stakeholder’s  ideal 
system.  The  following  is  the  questionnaire  that  was  provided  to  the  stakeholders. 
The  survey  questions  and  results  are  shown  in  Table  5. 

Questionnaire 

The  purpose  of  this  questionnaire  is  to  gather  information  to  create  an 
architecture  and  implementation  plan  for  a  VIRGINIA  Class  Launchers  KM 
system  database.  This  database  will  support  VIRGINIA  Class  tasking  and  may 
evolve  into  supporting  other  classes  as  well.  It  is  intended  to  support  daily  work, 
track  system  issues  (recurring  events,  etc.),  document  lessons  learned  from 
design  to  operation,  and  provide  an  external  reporting  system. 
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Table  5. 


Raw  survey  results 


What  are  your  current  problems  with  technical  data  availability  in  your  everyday  tasking? 

“What  specific  aspects  of  the  current  situation  are  unacceptable? 

The  Launchers  Division  has  no  central  paper  nor  digital  repository  of  data,  classified 
nor  unclassified.  Prior  management  positions  was  that  files  are  kept  at  the  TPM 
level.  In  current  reality,  personnel  (including  TPMs)  move  often  and  not  all  are/have 
been  as  knowledgeable/diligent  at  repository  of  information. 

As  an  organization  we  do  not  have  a  repository  of  ready-access  data  from  which  to 
make  educated  decisions  about  the  health  and  performance  of  systems  under  our 
cognizance.  For  example,  recurring  or  systemic  technical  problems  are  handled  on  a 
reactive  basis  as  they  are  discovered.  Farming  data  for  emerging  trends  is  not 
possible  at  this  time. 

Additionally  NUWC’s  responses  are  never  officially  recorded.  Most  activities  have  a 
way  they  document  problems  they  are  fixing  (i.e.,  ERs,  LARs,  etc).  NUWC  receives 
phone  calls  and  e-mails  and  responds  the  same  way. 

Lack  of  a  system  to  store  new  data  as  it  is  created.  The  majority  of  information 
systems  available  to  us  are  not  user  friendly  if  not  used  on  a  frequent  basis. 

Data  usually  exists  in  someone’s  desktop  files  but  must  be  reacquired  by  each 
individual  on  an  as  needed  basis. 

Handling  complications  required  because  documents  are  unnecessarily  entered  into 
the  U-NNPI(Unclassified  Naval  Nuclear  Propulsion  Information)  network. 

Current  technical  data  bases  are  mostly  from  experience  level.  The  senior 
engineers/Technicians  have  the  experience  in  various  areas  but  it  is  not  documented 
in  any  overall  database.  What  is  unacceptable  is  that  the  passing  of  knowledge  is 
almost  at  the  “tribal”  level.  The  junior  people  will  learn  if  the  senior  personnel  are 
outgoing  and  interested  in  passing  down  knowledge.  If  not,  the  knowledge  is  lost. 
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Conclusion 

Based  on  the  responses,  there  is  no  central  repository  for  data.  There  is  no  way  of 
transfer  of  tacit  knowledge  to  explicit  knowledge  to  train  new  employees.  There  is  no 
official  way  of  recording  data  or  one  mandated.  There  is  no  way  to  understand 
emerging  trends  on  existing  equipment. 

Do  you  have  a  system  in  place?  If  so,  what  are  the  strengths  and  weaknesses  of  the  system. 

This  can  include  your  own  or  the  organization’s  knowledge  management  system. 

There  is  no  comprehensive  system  in  place.  There  are  individual  systems  in  place, 
most  of  them  brute-force  manual  systems. 

There  are  difficulties  managing  data  with  different  classification  levels. 

The  three-inch  launcher  and  Trash  Disposal  Unit  (TDU)  In  Service  Engineering  Agent 
(ISEA)  has  a  paper  data  base  consisting  of  documents  generated  since  around  1980. 
The  System  Manager  has  about  8  four  tier  unclassified  lockers  in  his  office.  Each 
locker  has  numbered  folders  with  common  information  is  each  folder.  A  Microsoft 

Word  file  has  the  listing  of  each  locker  folder  and  the  title  of  each  separate  document 
in  each  folder.  One  has  to  use  the  search  program  to  find  the  locker  and  folder  for  the 
wanted  information.  The  strength  of  this  system  is  that  information  on  recurring  and 
unique  system  problem  areas  is  readily  at  hand  and  has  proven  to  greatly  successful 
for  everyday  problem  solving.  The  weakness  of  the  program  is  locker  space  to 
support  ever  growing  data  input  and  that  the  folders/locker  contains  superfluous 
information  that  never  has  been  thoroughly  reviewed. 

Conclusion 

There  is  no  comprehensive  system  in  place.  There  are  individual  systems  in  place 
and  data  needs  to  be  managed  at  different  classification  levels.  A  comprehensive 
system  of  managing  data  is  needed. 

What  part  of  the  current  system  works  well?  What  does  not  work? 

The  disaggregation  of  our  existing  systems  do  not  work  well.  The  manual  nature  of 
our  existing  systems  do  not  work  well. 

The  collection  and  implementation  process  does  not  work  well.  In  fact,  having 
multiple  systems  without  a  clear  direction  on  their  use  causes  them  to  act  as  black 
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holes. 


Holding  individual  copies  of  information  works  well.  However  it  is  not  available  to 
others. 

The  best  systems  are  user  friendly. 

The  system  is  detail  oriented  and  provides  great  background  on  recurring  problems. 
The  locker  area  is  finite.  The  creation  of  folders  is  labor  intensive.  Proposed  scanning 
of  existing  and  new  files  is  expensive. 

Individual  systems  work  well.  Some  have  great  detail. 

Conclusion  No  central  system  exists.  There  is  a  good  example  of  an  existing  system.  The 

system  varies  by  person  and  program.  The  KM  system  needs  to  be  user  friendly. 

What  functions  do  you  need  for  knowledge  management  in  your  tasking?  A  function  is  a  task 
the  system  performs. 

Document  management  (internally  generated  or  received  from  external) 

Digital  repository  with  paper  capability  (for  classified  or  sensitive  data) 

Ease  of  deposit  of  documents,  simplicity  of  addition  of  indicative  data  for  each 
document 

Title,  keywords,  author/division  POC,  date,  other  doc  numbers,  external  organization, 
funding  project,  etc  (perhaps  metadata  in  a  future  state) 

Flexible  reporting  of  the  KM  system  (allowing  management  to  pull  various  statistical 
information,  how  many  deposits,  deposits  bound  by  dates,  deposits  with  no  files 
attached,  etc...) 

Robustness  of  SEARCHING  for  data  (advanced  queries,  indexing  of  title,  keywords, 
etc  on  all  indicative  data 

Serve  as  a  historical  archive,  where  ongoing  and  future  engineering  efforts  can 
understand  and  incorporate  lessons  learned  in  the  past. 

Allow  external  sources,  such  as  supporting  contractors  and  program  sponsors  to 
monitor  health  and  performance  of  the  systems  in  near  real-time, 
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Allow  data  farming  to  identify  trends  in  order  to  move  our  work  to  a  more  proactive 
posture. 

Conclusion  The  primary  functions  requested  include  management  of  documents,  provides 

means  of  analysis,  allows  access  from  external  organizations,  and  supporting  several 
_ different  ways  to  search  for  information  in  the  archives., _ 

When  looking  for  Technical  Letters  what  process  do  you  use  to  find  these? 

I  can  never  find  the  letters  unless  I  wrote  them  or  reviewed  them. 

Ask  the  secretary  OR  a  TPM  OR  someone  that  was  involved  in  the  project.  Hit  or 

miss. _ 

In  some  cases  we  have  to  ask  external  sources  that  we  sent  the  letter  to. 

CITIS  but  it  is  sparsely  used 

Conclusion  There  is  no  formal  process  or  repository  for  storage  of  technical  correspondence. 

When  looking  for  drawings  or  manuals  what  process  do  you  use  to  find  these? 

ATIS,  CITIS,  or  ask  another  person  in  the  department. 

Not  certain  what  process  exists  for  pulling  Manuals 

Naval  Sea  Logistics  Center  which  is  required  to  keep  and  maintain  all  ship  logistics. 
Drawings,  depends  on  submarine  Class.  688,  726  and  21  are  available  via  ATIS; 

774  via  CITIS.  The  drawings  for  the  particular  equipment  I  am  responsible  for  are  not 
available  on  ATIS.  I  keep  them  on  my  hard  drive.  If  the  drawings  are  not  available 
via  ATIS  or  CITIS,  you  can  try  DAPS. 

Tech  Manuals  are  available  online  at  TDMIS,  but  it’s  not  very  user  friendly. 
Maintenance  Manuals,  Ship  Systems  Manuals  including  Ol’s,  Naval  Ship  Technical 
Manuals,  are  available  on  our  Department  Public  Drive.  ODs  you  go  to  Eric  Von 
Tish,  who  maintains  the  ODs.  The  library  has  some  tech  manuals,  and  has  an  online 
catalog  that  is  searchable. 

Conclusion  Drawings  and  Manuals  are  provided  by  external  organizations  primarily  through  two 
databases:  CITIS  and  ATIS.  This  function  should  remain  in  the  cognizant 
organization  due  to  the  cost  of  maintaining  an  up  to  date  database. 
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When  looking  for  Fleet  identified  problems  what  process  do  you  use  to  find  them? 

I  am  not  aware  of  a  comprehensive  database  that  stores  Fleet  identified  problems. 
The  Remedy  system  that  was  developed  to  track  Fleet  problems  and  resolutions  was 
terrible  and  was  never  used.  We  tried  to  develop  a  Remedy-lite  system  in  our  branch 
but  because  it  requires  additional  (redundant)  work  to  enter  information,  it  is  seldom 
used. 

Equipment  problems  that  are  reported  by  in-service  submarines  are  usually  reported 
as  requests  for  deviations  or  waivers.  There  is  an  E-DFS  site,  but  it  is  not  user- 
friendly. 

Locally  received  and  approved  deviations  and  waivers,  applying  to  work  being 
performed  under  contract  to  NUWC,  we  keep  in  a  database  developed  within  the 
Division.  But  it  is  only  a  few  years  old  and  doesn’t  contain  a  lot  of  data. 

Fleet  identified  problems  are  reported  by  deployed  submarines  via  Naval  Message. 

(A  couple  years  back  they  decided  to  include  SUBS  in  the  subject  line  of  these 
messages  to  make  them  easier  to  discern  and  track.  There  is  no  database  that  I  am 
aware  of  that  stores  Naval  Messages  beyond  30  days  after  issue.  Similar  to  technical 
letters,  Naval  Messages  will  only  be  available  if  of  critical  importance.  Naval 
Messages  are  most  likely  to  be  found  with  the  author  /  originator. 

Ask  an  ISEA(in-service  engineering  agent)  expert  from  that  system  area. 

Review  highlights  database 

I  wait  for  notification  from  them  via  naval  message.  This  has  not  been  an  effective 
method  of  communication  between  us  as  designer  and  them  as  end-user.  They  do 
not  have  robust  systems  on  their  end  so  entry  of  issues  at  the  source  is  not  always 
occurring. 
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Conclusion 

There  is  no  comprehensive  database  to  collect  launcher  related  data.  In  addition, 
not  all  problems  are  reported  on  the  user’s  end.  One  thing  that  did  not  come  out  in 
the  surveys  is  that  the  Fleet  uses  a  higher  classification  system  to  send  naval 
messages.  The  Launchers  Division  primarily  works  on  a  lower  classification  network. 

If  you  are  looking  for  the  configuration  of  a  system  on  a  certain  ship,  what  is  the  process  you 
use  to  find  it?  i.e.,  1  am  looking  for  an  all  the  engineering  reports  for  the  torpedo  tubes  how 
would  1  find  them? 

ATIS  contains  some  ships  configuration  data,  but  is  thought  out  of  date.  Ship  checks 
are  usually  required.  Or  a  phone  call  to  Fleet  personnel,  or  others  that  may  be 
“expert”  in  that  system. 

Conduct  a  ship  check,  as  1  would  not  believe  that  configuration  management  at  that 
level  would  be  reliable. 

The  tech  homepage  (which  is  described  in  the  Table  2). 

Conclusion 

This  is  a  similar  question  to  finding  drawings,  since  the  drawings  contain  the  majority 
of  the  configuration.  The  ships  drawings  are  large  in  multitude  and  would  be  hard  to 
maintain  them  up  to  date.  Ships  drawings  are  the  responsibility  of  the  planning 
yards. 

When  looking  for  calculations  what  process  do  you  use  to  find  them? 

To  the  best  of  my  knowledge,  only  SSDR  calculations  are  stored.  1  contact  the 
Planning  Yard  for  the  particular  submarine  class  via  LAR,  and  request  a  copy. 

Going  to  the  cognizant  engineer  or  technical  program  manager. 

Official  Calculations  are  stored  at  the  library  but  there  are  very  few  that  are  made 
official. 

In  local  directories 
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In  most  cases,  you  just  do  a  new  calculation.  Where  you  know  a  particular 
calculation  has  been  required  repeatedly,  and  will  be  needed  for  reference  in  the 
future,  it  is  best  to  document  such  an  analysis  or  calculation  in  a  TM.  These  are 
stored  in  the  NUWC  library  once  published. 

Conclusion 

A  process  for  storing  calculations  is  needed.  Means  of  generation  and  a  standard 
format  including  a  system  to  ensure  that  they  are  searchable  is  needed. 

When  looking  for  technical  specifications  what  process  do  you  use  to  find  these? 

Contact  Electric  Boat  or  Newport  News  Shipbuilding  and  issue  Liaison  Action 

Request  perhaps,  if  ATIS  does  not  possess  (which  it  would  not  for  tech  specs) 

Classified  Data  repository  for  Shipbuilding  Specifications. 

Internally  for  specific  equipment  specifications. 

Information  Handling  Services  is  the  best  place  to  find  up  to  date  specifications. 

Conclusion 

Storage  of  technical  specifications  is  outside  the  scope  of  the  thesis.  Only  specific 
specifications  are  kept  up  to  date  within  the  department.  Commercial  specifications 
are  available  via  the  NUWC  Library  and  would  be  too  hard  to  keep  up  to  date  since 
there  is  a  large  number  of  them  and  are  continuously  updated. 

When  looking  for  design  decisions,  what  process  do  you  use  to  look  for  them?  What  process 
do  you  use  to  document  them? 

1  would  look  for  drawing  Engineering  Change  Proposal’s  and  Technical  Variance 
Documents. 

CITIS  for  Engineering  Reports 

Unfortunately  there  is  not  a  division  wide  repository  for  such  information.  Within  my 
own  office  or  position,  the  files  of  all  predecessors  have  been  digitally  scanned,  but 
no  front  end  or  interface  is  available.  They  are  on  a  disk. 

There  is  no  official  process  to  document  them. 
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Conclusion  There  is  no  official  process  to  document  design  decisions  made  by  the  Launchers 
Division. 

What  is  the  most  important  data  required  to  conduct  your  tasking? _ 

My  personal  digital  files. 

End-user  feedback  of  issues  discovered  during  operation,  (i.e.,  Fleet  input). 

Anything  that  answers  the  question:  how  did  we  get  here?  That  would  include 
background  information  on  the  tasking  in  question,  which  is  usually  documented 
formally  in  test  plan/report  front  matter,  and  in  the  background  paragraphs  on  letters 
to/from  NAVSEA. 

All  of  the  data  you  have  mentioned  above:  drawings,  configuration  of  a  particular 
ship,  deviations  and  waivers,  calculations,  tech  manuals,  test  results.  In  addition, 
LARs,  procurement  history  (list  of  previous  suppliers,  in  particular). 

Materials  information,  detailed  requirements  documentation,  and  vendor  data. 
Conclusion  Technical  documentation  needs  to  be  stored.  All  relevant  design  data  is  important 
including  drawings,  calculations,  and  technical  manuals. 

What  is  the  least  important  data  required  to  conduct  your  tasking? 

I  don’t  know  the  entirety  of  the  data  I  work  with 

Extraneous  “chatter”  in  emails,  frequently  surrounding  those  1-2  sentences  of 
information  that  I  actually  need.  (A  more  efficient  keyword  search  in  Outlook  would 
be  nice.) 

Old  contracts 

Irrelevant,  usually  e-mails  from  other  people  who  are  answering  commitments  that 
have  no  relevance  to  what  I  am  doing. 

Conclusion  This  question  had  some  responses  and  could  have  been  accomplished  in  a  different 
manner.  Overall  it  is  important  to  document  most  technical  data. 

When  looking  for  test  results  (at  sea,  DT  and  OT)  what  process  do  you  use  to  obtain  these? 

Ask  those  who  were  likely  to  have  participated  in  these  events  in  the  past. 
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Go  to  Code  25  folks,  but  unfortunately  their  objectives  center  on  testing  Non 

Propulsion  Electronic  System  functionality  and  they  often  record  issues  with  my 
system  as  an  afterthought.  If  our  folks  participated  in  the  test,  1  may  be  able  to  review 
their  trip  reports.  Unfortunately,  it  is  not  mandatory  to  fill  out  a  trip  report  and  most 
that  1  have  gotten  were  due  to  my  nagging,  not  their  management’s. 

Test  results  are  usually  documented  in  the  test/trip  reports,  which  are  usually  found 
as  enclosures  -or  at  least  references-  to  NAVSEA  letters.  Raw  data  is  usually 
archived  on  CDROMs/DVDs  or  network  servers,  and  can  usually  be  found  via  the 
dates,  test  facilities,  and  SMEs  named  in  the  applicable  reports. 

For  in-service  submarines,  1  believe  SUBMEPP  maintains  copies  of  completed  test 
forms.  1  contact  my  SUBMEPP  POC  and  ask.  If  the  maintenance  activities  have 
forwarded  the  results,  SUBMEPP  will  have  them.  For  Maintenance  Requirement 
(MR)  cards  other  than  K-type,  go  to  the  local  Intermediate  Level  Maintenance  Activity. 

For  new  construction  submarines,  1  believe  the  Shipbuilders  maintain  copies  of 
completed  test  forms.  For  results  of  K-type  MR  cards,  go  to  the  local  Performance 
Monitoring  Team.  (Inexplicably,  data  from  K-type  MR  cards  is  not  made  available  to 
ISEAs  for  evaluation.) 

Go  to  the  Code  25  contractor  run  deviation  tracking  system  that  has  all  of  the  test 
findings 

Conclusion 

Test  results  from  equipment  tested  ashore  are  easier  to  find  than  at  sea  system 
testing.  At  sea  system  test  data  is  important  to  understand  the  strong  and  weak 
areas  of  the  systems.  Understanding  this  allows  for  improvement  of  the  current  and 
development  of  future  designs. 

Would  a  knowledge  management  system  tool  be  useful  in  conduct  of  your  work? 

Any  organized,  comprehensive,  searchable  DOCUMENT  MANAGEMENT  system 
would  be  hugely  beneficial. 
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I’d  say  that  it  is  critical  and  in  fact  we  are  not  doing  our  job  effectively  without  out. 

The  submarine  community  is  wasteful  at  this  point  in  time,  working  issues  over  and 
over  again  without  even  knowing  it. 

Conclusion 

A  knowledge  management  system  is  important  for  conduct  of  work  and  will  be  useful 
to  the  Launchers  Division. 

Do  you  know  of  instances  where  technical  data  is  unavailable  that  you  need.  If  so  what  are 
they?  How  can  this  problem  be  solved? 

This  happens  each  and  every  day  here.  There  are  no  central  repositories  (within 

Code  412  at  least!)  to  store  and  disseminate  data.  Our  technical  library  has  not 
embraced  this,  not  sure  why.  Other  organizations  are  moving  towards  efficient 
enterprise  wide  solutions,  and  we  are  still  relying  on  manual  based  processes,  or 
simply  “people”.  Which  is  great  until  those  people  go  away. 

Being  redundant,  but  we  NEED  a  centralized  solution  for  document  repository.  It 
needs  to  be  simple  to  upload  the  document  along  with  any  indicative  data,  and  needs 
to  have  robust  search  capabilities. 

A  good  example  would  be  sea  trial  results,  which  are  currently  classified  at  a  level  1 
can’t  access  simply  because  it  was  conducted  by  a  test  group  that  is  accustomed  to 
working  with  data  also  collected  during  the  test  that  1  don’t  even  need. 

For  a  current  project  we  are  looking  for  design  performance  data  of  a  particular  piece 
of  equipment  in  order  to  assist  with  computer  modeling.  The  information  that  we 
require  does  not  appear  to  be  available.  Our  options  are  to  keep  looking,  or  try  to 
recreate  the  data  empirically. 

1  don’t  have  access  to  a  database  that  quantifies  the  failures  in  my  area.  There  is  a 
“3M”  system  but  1  don’t  have  a  way  of  getting  to  it.  Establish  a  link  to  it  for  NUWC, 

Code  40. 

Yes,  there  have  been  several  times  that  1  needed  688  class  SSDRs  and  NUWC  did 
not  have  them..  1  had  to  get  them  from  the  688  Class  PY. 

Conclusion 

There  are  many  instances  of  missing  technical  data. 
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If  you  were  going  to  create  the  system,  what  functions  would  it  perform  and  how  would  it  be  set 
up? 

See  functions  above 

It  would  be  accessible  and  easy  to  use.  Something  simple  and  elegant  is  required. 
Too  many  of  the  competing  systems  have  a  “whiz-bang”  feel  reflecting  a 
programmer’s  interests  and  not  those  of  the  actual  users.  It  would  be  universal, 
meaning  that  all  relevant  participants  of  this  diverse  technical  community  would  see  it 
as  the  sole  repository,  as  such  it  would  become  comprehensive.  It  would  be 
mandatory  because  we  unfortunately  are  working  in  an  atmosphere  of  complacency 
and  entitlement. 

It  would  be  available  online,  accessible  from  anywhere.  It  would  be  a  comprehensive 
system,  containing  drawings,  deviations,  manuals,  etc  all  in  one  system  or  at  least 
through  a  common  portal  or  interface.  It  would  be  readily  searchable  by  keywords, 
dates,  author,  etc.  It  would  be  continuously  updated  without  any  additional  work  on 
the  part  of  the  user.  It  would  be  maintained  by  dedicated  personnel  who  are  skilled  in 
archiving.  It  would  be  a  system  that  could  be  relied  on  to  still  be  in  existence  and 
available  5,  10  or  15  years  down  the  road. 

Prior  to  NMCI,  many  of  us  had  Google  Desktop  installed  on  our  computers.  This  was 
a  great  tool  to  search  through  all  your  files,  emails,  etc.  at  once. 

Backed  up  regularly  for  access  should  the  network  become  unavailable  for  a  period 
of  time. 

Conclusion  The  functions  are  defined  in  the  question  above  and  in  a  previous  question. 

What  type  of  data  are  you  looking  to  store?  And,  how  long  do  you  need  to  keep  it?  And,  what 
are  the  known  relationships  between  those  pieces  of  data? 

Need  to  store  outgoing  responses  to  shipyards,  research  about  problems  for  future 
use,  test  reports  etc... 
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Types  -  ALL  types.  Any  “product”  that  we  create.  I  define  a  product  as  any 
document  that  we  send  out  to  a  stakeholder  (white  paper,  presentation,  letter),  or  that 
we  use  internally  to  perform  our  work  (test  plan,  test  report,  controlled  work  package, 
calculation  package,  etc). 

How  long  to  Keep?  Forever 
Unknown 

For  example,  shock  qualification  data  should  probably  be  stored  as  long  as  the 
subject  system  is  deployed,  i.e. ,  forever  (effectively).  Available  historical  data  should 
facilitate  reverse-engineering  any  system,  by  anyone  with  relevant  technical 
knowledge/expertise  and  need-to-know. 

Data  needs  to  be  stored  for  the  life  of  the  particular  submarine  or  submarine  class. 
Typically,  30  years  or  so. 

Ongoing  and  historical  type  data.  I  don’t  know.  I  know  ours  works  but  it  would  be  very 
cumbersome  on  a  Fleet  wide  level. 

Conclusion  All  types  of  technical  data.  The  size  stored  will  depend  on  the  system  defined.  The 
system  has  to  store  data  for  at  least  thirty  years. 
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APPENDIX  B:  SYSTEM  CONCEPTS 


Function  Requirement 
Number  Number 


1.0 


KM1.0 


System  Requirement 


System  shall  be  able  to  generate  data. 
Generation  of  data  includes  facilitation  of  the 
Figure  6  knowledge  cycle.  This  includes 
standard  templates  for  generation  of  letters, 
calculations,  and  drawings. 


Concepts 


1.1  KM1.1 


1.1  KM1.2 


1.2 


KM  1.2 


The  system  shall  be  able  to  create  data.  This 
includes  standard  templates  for  generation  of 
letters,  calculations,  and  drawings. 


System  shall  be  able  to  assist  in  translation  of 
tacit  to  explicit  data.  This  shall  include 
shadowing  of  experts  to  understand  how  the 
task  is  completed.  Followed  by  translation  of 
the  tacit  knowledge  (understandingO  into  a  form 
that  can  be  used  by  others.  Other  methods  can 
be  used  to  accomplish  this  task. 


System  shall  create  incentive  for  users  to 
create  and  share  knowledge 


Automatic  Templates  for  technical  documentation. 


Create  standard  procedures  developed  by  the  department  to 
create  technical  documentation  including:  calculations,  test 
reports,  letters,  drawings  and  other  technical  documentation. _ 

Create  department  policy  with  a  person  that  is  in  charge  of 
standardization  of  technical  documentation. 

Voice  Recognition  software  to  capture  meeting  minutes,  write 
letters,  and  create  other  documentation. 

Procedures  for  standardization  of  documentation. 

Requirement  for  documentation  in  certain  cases. _ 

This  can  be  done  in  second  increment 
Translation  trade  by  one  group  into  documentation. 

Translation  of  design  methodology  into  details  using  diagrams 
and  instructions. _ 

Training  on  how  to  do  this 

Requirements  for  personnel  to  accomplish  this. 

Put  it  in  Performance  Review  which  directly  affects  raises,  NUWC 
is  under  a  pay  for  performance  system. 

Have  a  bonus  for  personnel  contribute  to  the  overall  system. 

End  of  year  award  for  this. 


71 


Function  Requirement  System  Requirement 
Number  Number 


2.0 


KM2.0 


The  system  shall  be  able  to  assist  in  translation 
of  tacit  to  explicit  data.  This  shall  include 
shadowing  of  experts  to  understand  how  the 
task  is  completed.  Followed  by  translation  of 
the  tacit  knowledge  by  changing  it  into  a  form 
that  can  be  used  by  others.  Other  methods  can 
be  used  to  accomplish  this  task. 


2.1  KM2.1 


2.2  KM2.2 


3  KM3.0 
3  KM3.1 


The  data  shall  be  able  to  be  entered  by  all 
users.  Users  include  Launchers  Division 
personnel,  NAVSEA  headquarters  employees, 
and  Fleet  Personnel  with  access  to  NMCI. 

The  system  shall  have  the  ability  to  sort  data  by 
system  and  project.  Systems  include  torpedo 
tube,  weapon  shipping  and  handling,  internal 
countermeasure  launcher,  external  and  internal 
countermeasure  launchers,  trash  disposal  unit, 
surface  vessel  torpedo  tubes,  weapon  shipping 
and  handling,  and  vertical  launch  systems.  The 
system  shall  include  the  ability  to  sort  data  by 
project. 

The  system  shall  provide  the  ability  to  store 
data. 

The  system  shall  store  technical 
documentation.  Technical  documentation 
includes  letters,  calculations,  liaison  action 
requests,  drawings  and  can  be  expanded  to 
other  documents. 
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Concepts 


Upload  it  electronically  into  system 
Place  it  in  paper  repository 


Easy  to  use  computer  interface. 

Paper  insertion  into  the  files. 

Automatic  input  by  email  or  other  means. 


Users  have  to  designate  what  system  using  a  check  box 
The  system  searches  for  keywords  and  places  it  in  the  right  file. 
System  operation  on  an  accessible  network  with  hard  drives  and 
software  to  support  it. 

File  Cabinets  with  workers  to  provide  them  when  needed. 


Electronic  Repository  to  store  the  documentation. 


Function  Requirement  System  Requirement 
Number  Number 


3 


KM3.2 


The  data  storage  capability  shall  be  expandable 
to  meet  the  needs  of  the  division. 


4.1 


4.2 


5.0 


KM4.0 


KM4.1 


KM4.2 


KM5.0 


The  system  shall  provide  the  ability  to  analyze 
data.  Analysis  includes  input  and  output 
metrics.  Analysis  includes  identification  of 
system  issues  (the  second  part  can  be  a  follow 
on  capability) 

The  system  shall  be  able  to  analyze  launcher 
system  data.  This  function  shall  be  performed 
by  launchers  personnel  or  a  software  program. 

The  system  shall  provide  input  and  output 
metrics.  This  is  the  number  and  size  of 
documents  handled  by  this  system. 

The  system  shall  provide  the  ability  to  report 
data.  This  includes  providing  data  files  that  are 
contained  within  the  system. 


5.1 


KM5.1 


The  system  shall  be  able  to  be  searchable  for 
all  documentation  contained  within  the  system. 
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Concepts 


Additional  hardware  can  be  hooked  into  the  system. 


Data  partitions  in  paper  file 
See  sub  requirements 


Manual  search  for  similar  problems  by  launchers  personnel. 
Statistics  generated  for  failure  rates  and  operational  availability. 


Software  to  measure  system  usage.  This  includes  areas  they  are 
used.  There  is  commercially  available  software  for  this 
application _ 

For  paper  repository  the  files  can  be  tracked  manually 


Google  search 
Wiki  type  interface 

I  wish  it  could  be  automatically  sent  to  the  user. 


Function  Requirement  System  Requirement 
Number  Number 


5.2 


KM5.2 


The  system  shall  be  able  to  provide  data  files 
that  are  contained  within  it.  Different  levels  of 
access  shall  be  used  depending  on  the  project 
and  classification. 


KM  5.3  Data  reporting  is  providing  the  data  to  the 

users.  The  data  shall  include  reports 
generated,  letters,  white  papers,  and  other 
technical  correspondence  that  is  contained 
within  the  system. 


6  KM6.0 


6.1  KM6.1 


The  system  shall  facilitate  knowledge  sharing. 
Knowledge  sharing  is  passing  information 
between  individuals  and  organizations. 

The  system  shall  facilitate  transfer  of 
knowledge  between  individuals.  Transfer  of 
knowledge  shall  be  accomplished  through 
multiple  forms  of  communication.  The  forms  of 
communication  shall  include  written  and  oral. 


6.2 


KM6.2 


The  system  shall  be  capable  of  sharing 
knowledge  to  organizations  which  includes 
NAVSEA,  ONR,  the  Fleet,  and  contractors  of 
the  Launchers  Division. 


KM7.0  The  system  shall  have  the  ability  to  meet  the 

Department  of  Defense  information  assurance 
security  requirements. 
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Concepts 


by  email  files. 


I  wish  it  could  be  direct  access. 
Software  access 


Network  access 


Use  current  ipt  structure  and  force  additional  individuals  to 
participate. 


Change  environment  through  cultural  change. 

Representatives  could  be  sent  to  Fleet  post  deployment,  similar  to 
TOMIS  system. 


Technical  documentation  to  be  sent  to  Fleet. 

Fleet  representatives  should  be  part  of  program  reviews. 


Function  Requirement  System  Requirement 
Number  Number 


KM8.0 

KM9.0 

KM10.0 

KM11.0 

KM12.0 

KM13.0 


The  system  shall  be  able  to  adapt  to  new 
requirements  and  functionality. 

The  user  interfaces  shall  be  similar  to  ones  that 
are  already  used  such  as  common  internet 
search  engines,  common  data  reporting  similar 
to  formats  used  in  the  Division. 


The  system  shall  last  30  years 


The  system  shall  have  back  up  data  storage, 
processing,  and  power  supplies. 


The  system  shall  be  compatible  with  the  Naval 
Marine  Corps  Intranet. 

The  system  shall  be  based  on  KM  best 
practices  including  Management  Champion, 
Community  of  Practice,  Technology,  and 
Processes. 
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Concepts 


Operating  system  has  the  ability  to  add  software  and  files  be  able 
to  interact  with  the  software. 


Use  Upload  Buttons. 

Use  up  to  date  search  tools.  These  include  Google,  wiki,  Bing 
search  engine  and  tools  that  are  familiar  to  people.  Google  has 
NMCI  capable  software. _ 

Data  presentenced  in  a  read  able  manner. 

Security  system  partitioned  off  the  system. 

Use  standard  file  formats,  word,  pdf  that  will  be  able  to  be  read  for 
a  while. 

System  could  maintain  older  software  to  pull  up  the  file  formats 
needed. 


Back  up  hard  drives  that  save  material 

Dual  backups 

Back  up  operating  system. 

Use  TOMIS  for  data  storage.  The  engineers  have  the  experience 
to  complete  this  type  of  tasking. 


Design  and  Test  software  to  comply  with  NMCI  rules. 


Combinations  of  technologies.  Incentives,  and  processes. 
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